Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Critical
-
Resolution: Fixed
-
Affects Version/s: 1.3, 1.3.1
-
Fix Version/s: 1.3.2
-
Labels:None
-
Number of attachments :
Description
If you call:
tm.getTransaction().registerSynchronization(sync1)
from within a Synchronization and that Synchronization tries to register another Synchronization with a different position using this:
tm.getCurrentTransaction().getSynchronizationScheduler().add(sync2, X)
with X different than 0 (the default position used by Transaction.registerSynchronization()) then the TM will throw a ConcurrentModificationException from BitronixTransaction.fireBeforeCompletionEvent() that will mark the transaction as rollback only.
This is only possible to do by using BTM calls as the standard JTA API calls always work with the default position. This can be triggered by a side-effect of calls BTM does inside Synchronization it registers itself at non-default priority. For instance, getting a connection from the pool from inside a Synchronization makes BTM register a new Synchronization with non-zero priority.
See: http://www.nabble.com/Exception-with-new-version-of-Bitronix-td19724399.html
Activity
| Field | Original Value | New Value |
|---|---|---|
| Description |
If you call: tm.getTransaction().registerSynchronization(sync1) from within a Synchronization and that Synchronization tries to register another Synchronization with a different position using this: tm.getCurrentTransaction().getSynchronizationScheduler().add(sync1, X) with X different than 0 (the default position used by Transaction.registerSynchronization()) then the TM will throw a ConcurrentModificationException from BitronixTransaction.fireBeforeCompletionEvent() that will mark the transaction as rollback only. This is only possible to do by using BTM calls as the standard JTA API calls always work with the default position. This can be triggered by a side-effect of calls BTM does inside Synchronization it registers itself at non-default priority. For instance, getting a connection from the pool from inside a Synchronization makes BTM register a new Synchronization with non-zero priority. See: http://www.nabble.com/Exception-with-new-version-of-Bitronix-td19724399.html |
If you call: tm.getTransaction().registerSynchronization(sync1) from within a Synchronization and that Synchronization tries to register another Synchronization with a different position using this: tm.getCurrentTransaction().getSynchronizationScheduler().add(sync2, X) with X different than 0 (the default position used by Transaction.registerSynchronization()) then the TM will throw a ConcurrentModificationException from BitronixTransaction.fireBeforeCompletionEvent() that will mark the transaction as rollback only. This is only possible to do by using BTM calls as the standard JTA API calls always work with the default position. This can be triggered by a side-effect of calls BTM does inside Synchronization it registers itself at non-default priority. For instance, getting a connection from the pool from inside a Synchronization makes BTM register a new Synchronization with non-zero priority. See: http://www.nabble.com/Exception-with-new-version-of-Bitronix-td19724399.html |
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Status | Resolved [ 5 ] | Closed [ 6 ] |
The bitronix.tm.utils.Scheduler$SchedulerIterator class has been changed so that it does not uses iterators internally anymore but a very careful index-based manual iteration algorithm instead.
New Synchronizations can now be added to a priority or in a newer priority without breaking the iteration. A new test has been written to assert this.
A snapshot build has been published and the user reported that the issue got solved.