Yes, this is what I have been going on about for the last couple of weeks.
The session must be enlisted in the JTA tx *before* delivery occurs from the messaging
provider, otherwise, to the provider the delivery was non transacted, since it didn't
know about the tx at the time it delivered the message to JCA. So when you rollback it
won't know about the delivery.
This is what is covered in ML's tx book chapter 5 what I was talking about.
You don't any kind of special message listener to do this correctly. You just need
to:
a) When the listener is first created and before it is added to the session, enlist the
session for the first time. Then by the time onMessage is called you know the session is
already enlisted,
b) in *your* onMessage (JBMMessageHandler:onMessage) call the delegate onMessage, then
delist and commit, then.... before returning from your onMessage, enlist the session again
so by the time the next onMessage is called it's already enlisted,
Note however, you shouldn't be using the tm.begin(), tm.commit() methods. These
require commit or rollback to be called on the same thread as beging, which won't
necessary work since subsequent invocations of onMessage can be called on different
threads.
You should therefore cache a reference to the JTA transaction object and call commit/
rollback directly on that since it does not require same thread to call it, and moreover
JBM does not care about transaction-thread associations.:
JTA spec, section 3.3.3
anonymous wrote :
|
| The Transaction.commit and Transaction.rollback methods allow the target
| object to be comitted or rolled back. The calling thread is not required to have the
same
| transaction associated with the thread.
|
|
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213668#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...