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


      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 {





      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 {



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







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



        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