-
1. Re: StdServersession too late for transaction?
Or should the XARessource.start(...) method be implemented
in such a way that it "picks up" the work done after
the last commit?
This not my understanding of the XARessource`s
responsibilities.
What do you think? -
2. Re: StdServersession too late for transaction?
> In the StdServerSession of jboss a new transaction is
> begun
> in the onMessage() method, NOT in the start()-method,
> so
> my XASession is enlisted after it consumed the
> message and
> called the onMessage() method.
That's correct. The actual message consumption is done from the ConnectionConsumer outside the tx and the association to the actual XASession must be done from the provider during XAResource.start() which is called within the sessionListener's onMessage() call.
> Isn't the tm.begin() too late in StdServerSession?
> Am I something missing here?
If the tx were started in the serverSession.start() method, you would not be able to load a serverSession with multiple messages. According to the EJB spec, each message has to be delivered in a distinct tx context and thus the XAResource must be enlisted during the sessionListener.onMessage() call. If you provider has a problem with that, it is probably not compliant here.
-- Andreas -
3. Re: StdServersession too late for transaction?
Thank you Andreas, I think I got your point.
The ServerSession must of course
have a separate transaction
for each onMessage()-invocation.
But the reason to enlist the XASession in this
transaction is to allow rollback of the
message consumption.
So now I modified my XASession/XARessource to
allow getting enlisted AFTER the consumption was done.
This works now (!), so perhaps I should shut up, but
then again there is something I don't understand
about this:
Is this semantic of an enlist()-call ("picking up work
done before") compliant with XARessoure in general or is
it only ok when the XASession is used in "application
server mode".
In my understanding so far an XARessource should throw a
XAException(XAException.XAER_OUTSIDE) if work had been
done before the XARessource.start(xid).
Any comments about this?
-- Michael
PS.: Shouldn't the StdServerSession use an already existing
tx anyway? -
4. Re: StdServersession too late for transaction?
> Is this semantic of an enlist()-call ("picking up
> work
> done before") compliant with XARessoure in general or
> is
> it only ok when the XASession is used in
> "application
> server mode".
This semantic applies in conjunction with a connection consumer. Without that (e.g. calling receive) you have to enlist the XAResource before message consumption.
A connection consumer consumes messages outside of any tx, picks up a server session from the pool, loads the associated JMS session with messages and calls run. The JMS session is responsible to deliver each message in their own XA tx, thus, it must associate the message to the XA tx before it is actually delivered to the MDB. One way to implement it is to watch when the XAResource gets enlisted (start) and do the association here (the way JBoss/JBossMQ/SwiftMQ does it), another way is to use call backs from the app server (beforeDelivery/afterDelivery) (the way the JMS RI does it). The implementation isn't specified anywhere, only the semantic (single tx) is.
> In my understanding so far an XARessource should
> throw a
> XAException(XAException.XAER_OUTSIDE) if work had
> been
> done before the XARessource.start(xid).
But it hasn't be done. The tx is started, the message is associated, XAResource.start returns. Everything is ok.
-- Andreas