JBossDeveloper

This sounds like feature creep. We agreed that the ASSOCIATED and DISASSOCIATED event callbacks were sufficient for your use case. Of course it is straightforward to add a third one for DISASSOCIATING so if you are saying that your implementation needs that extra event then we can certainly include it but it is adding more overhead to each transaction. If you do need it maybe we can look at make the registration process more fine grained so that listeners may listen for a subset of the available events to avoid superfluous callback invocations.

Here's a suggestion. I will commit a (SNAPSHOT) version that includes all 3 events and then you can prototype your solution. If after that exercise we discover that we only require a subset of the events then we can prune accordingly.

So the plan is to satisfy Scotts requirements by supporting notifications for ASSOCIATED which is the resume (and the initial register of the callback) and DISASSOCIATING which includes commit, rollback and suspend. The notification invokes the listener with the transaction and the EventType (ASSOCIATED or DISASSOCIATING).

But Jesper has a use case where we need these cases separated - e.g. begin() != resume(), and commit() != rollback() != suspend().

I propose that we support this use case by adding a "reason" field to the notification payload where reason is one of begin/suspend/resume/commit/rollback. Is this good enough?

Earlier posts here have expressed a requirement for extensibility but Java enums are final classes so I have opted for the following proposal instead:

// base interface for event types

  public interface EventType { String getName(); }

// register interest in one or more event types

  public void addListener(TransactionListener listener, EventType ... types);

// registration process

  public interface TransactionListenerRegistry {

     void addListener (TransactionListener listener, EventType ... types);

     boolean isSupported(EventType type);

  }

// event types for thread association

  public enum ThreadAssociationEventType implements EventType {

    ASSOCIATED, DISASSOCIATING;

  }

// event types for the transaction lifecycle

  public enum TransactionLifecycleEventType implements EventType {

    BEGIN, ABORTING, COMMITTING ;

  }

Sott needs ThreadAssociationEventType and Jesper wants TransactionLifecycleEventType

If we need more events then we will implement more EventTypes for them.

If we can agreement soon we can hit the release that Tom is about to do.

mmusgrov wrote:

 

// event types for thread association

  public enum ThreadAssociationEventType implements EventType {

    ASSOCIATED, DISASSOCIATING;

  }

// event types for the transaction lifecycle

  public enum TransactionLifecycleEventType implements EventType {

    BEGIN, ABORTING, COMMITTING ;

  }

TransactionLifecycleEventType is probably not enough for Jespers use case. Jesper, which subset of {SUSPENDING, SUSPEND, RESUMING, RESUME, COMMITTING, ABORTING} do you need ( ABORTED and COMMITTED) are available via synchronizations.

Mark Little wrote:

 

A "reason" field? Seems like overkill. Why not just make the event type more explicit then? SUSPENDING, COMMITTING, ROLLINGBACK, ..?

Also, the reason I suggested a reason field was to avoid having multiple types for the same underlying event. For example the notifications DISASSOCIATING and SUSPENDING are produced when suspend() is called so semantically it is one event and there are different reasons for that event.

A "reason" field? Seems like overkill. Why not just make the event type more explicit then? SUSPENDING, COMMITTING, ROLLINGBACK, ..?

As a side note, earlier posts on this thread did propose a more complete set of states but that approach was abandoned using the argument that we should:

• only provide enough states for the known use cases;
• make sure the event type state space and implementation is extensible so that we can support future use cases;