BTM
  1. BTM
  2. BTM-31

Synchronization registering another Synchronization with a different position aborts transaction

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.3, 1.3.1
    • Fix Version/s: 1.3.2
    • Labels:
      None
    • Number of attachments :
      0

      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

        Hide
        Ludovic Orban added a comment -

        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.

        Show
        Ludovic Orban added a comment - 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.

          People

          • Assignee:
            Ludovic Orban
            Reporter:
            Ludovic Orban
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: