1 2 3 Previous Next 70 Replies Latest reply on Apr 18, 2015 10:46 AM by mmusgrov

    Requirement for an observer SPI for tracking thread-to-transaction association changes

    mmusgrov

      This is the follow up to the thread Re: Design Discussion: Changing the reaper to use setRollbackOnly() instead of rollback() where the requirement for a new SPI for clients such as JPA and IJ to listen for thread-to-transaction association changes arose. Comment number 72 summarises the current proposals for the new SPI which I will repeat here:

       

      Option 1)

       

        public interface ThreadAssociationListener extends Synchronization {

          public void threadAssociated();

          public void threadDisassociated();

        }

       

      A somewhat improved interface exposes a simple extensible state model:

       

      Option 2)

       

        interface ExtendedTransactionListener {

          void stateChange(TransactionEvent e);

        }

        enum TransactionEvent {

          ASSOCIATED,

          DISASSOCIATED

        }

       

      Here we shy away from adding any state changes that are already provided by javax.transaction.Synchronization.

       

      This option is nice because:

      - it is sufficient to addresses the problem in hand, and

      - it is extensible in the event of future requirements

       

      Jesper argues for a more generic approach (to avoid having to revisit it if future requirements crop up in this area):

       

      Option 3)

       

      Something along the lines of:

       

      interface TransactionLifecycleListener {

          void before(TransactionLifecycleEvent e);

          void after(TransactionLifecycleEvent e);

      }

       

      enum TransactionLifecycleEvent {

        ASSOCIATED,

        START,

        PREPARE, NO_PREPARE /* in case there is no prepare() call */

        ...,

        BEFORE_COMPLETION,

        AFTER_COMPLETION,

        DISASSOCIATED

      }

       

      The TransactionLifecycleListener methods could even take a Object... payload parameter such that the implementation could do something like:

       

      after:

        if (ENLIST.equals(e)) {

          XAResource xares = payload[0];

          // do stuff

        }

       

      This option needs further discussion:

       

      - why do we need before and after

      - why do we need the extra lifecycle callbacks (such as the implied ENLIST event, what is START), some use cases would be desirable;

      - should we be duplicating lifecycle callbacks that are already available via javax.transaction.synchronization.

        1 2 3 Previous Next