send jms message after tx commit

[justkeys]

Example: after the invocation of a Person insertPerson() method on a @Stateless or @Service, i would like to broadcast this new person to a jms topic. But this notification should only happen if the transaction commits, not if it rolls back.

EJB3 interceptors are always inbetween the container tx interception and the implementation, so they dont know whether the tx committed, since it has not yet been committed when they get control again, after the invocation.

1. I read about the SessionSynchronisation interface, but it's for @Stateful ejbs only. Any particular way i could enable this on @Service?
2. Perhaps the jms-sender code needs to be transaction-aware, and postpone the send until the tx commits? Is this possible?
3. I could insert an ejb3 handcoded transaction interceptor, (and annotate the ejb "supports") so that i can order it after my jms-sending interceptor. Can i re-use jboss code, or do i have to reimplement this transaction-interceptor as ejb3 interceptor?
4. Or i can make a "NotifyingEJB3" that has "supports", and takes care of forwarding to the actual implementation ("required"), and then sends out the jms message.

Other possibilities?

[jaikiran]

Perhaps the jms-sender code needs to be transaction-aware, and postpone the send until the tx commits? Is this possible?

If you include the message sending functionality as part of the same transaction which saves the Person, then the "send" will only happen on a successful commit of the transaction.

[justkeys]

http://www.odi.ch/prog/jms-tx.php explains transactional jms quite well.

[justkeys]

jaikiran, i think your statement is incorrect: even though i am using @Resource(mappedName="java:/JmsXA"), my messages still get processed before the data is actually visible in the database.

When i add logging, it's a matter of 100 ms.

So my explanation for this is: 2 phase commit guarantees that all resources will commit (end of phase 1), but it does not guarantee any timing about it, therefore the thread handling the message may read the db sooner than the db makes its changes visible. I'm not sure if this reasoning is correct, please give me your thoughts on it.

[gandhirajan]

Hi, Did someone managed to resolve this race condition? Could someone please provide an update on this?