apache
Inconsistent timer view when using quartz persistence
In TomEE timers are stored twice. Once in the TimerStore and once in the quartz scheduler. Quartz itself may use in memory or database storage. It is hard to keep both stores in sync, especially if database persistence is used in quartz and TomEE is restarted. This leads to inconsistencies.
This pull request tries to avoid the inconsistencies by removing one storage location (TimerStore).
I like the idea but think it doesnt work cause we need to handle transactionality there so we need to enhance TimerStore to rely more on quartz outside of transactions, no?
I am not sure if I really understood the question. But I see three cases:
- Manipulation of persisted timers within a transaction. This should be handled perfectly using persistent quartz timers, since the database connection takes part in the transaction.
- Manipulation of persisted timers outside a transaction. This might fail. But I am not sure what the EJB specification says about this and if it even makes sense to do so.
- Manipulation of non persisted timers. Here my current patch seems to be overkill (unless if running in a cluster environment), since timers are persisted and deleted during restart. I like the idea of an independent Quartz-Scheduler for non-persistent timers.
On 19.05.2017 00:37, Romain Manni-Bucau wrote:
I like the idea but think it doesnt work cause we need to handle transactionality there so we need to enhance TimerStore to rely more on quartz outside of transactions, no?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/apache/tomee/pull/64#issuecomment-302560467, or mute the thread https://github.com/notifications/unsubscribe-auth/AGZFDmLI-cglUq24UhxL9_JZDDs0Zlohks5r7MgTgaJpZM4MfLod.
You are kind of right except assuming we use a db which will not be the default (memory) so 1 is an issue in this case. Said otherwise i like the move of this pr but it would break ejb spec in most cases (few users rely on jdbc).
OK, I do not remember excatly what I was doing in this pull request. But it seems that the whole work is still done in TimerService.transactionComplete(). So the main functionality is left untouched. And I wonder why it works with "org.apache.openejb.quartz.impl.jdbcjobstore.JobStoreTX" since the transaction is already completed.
I think all test cases in container/openejb-core still work. It would be interesting to find a test case that works in original openejb and not in the pull request.
A user reported jobstoretx was not working and digging into it i realized it cant work until you hack the container so sounds unsane :s.
We also have some close tests due to oracle licensing so maybe coverage is not great on os side