No LastResource gambit for non-xa MDB

[adrian.brock]

If the MDB uses a connection factory that is not XA,
it drives the transaction, but uses an unlinked JMS local tx commit()

We should really be wrapping this in a pretend XAResource like LocalXAResource in JCA
that is tagged with LastResource so it can take part in the "last resource gambit".

[weston.price]

Do we really want to do this on the receipt? The receipt of the message, if using Local transactions really should be independent of the Global transaction as it is only used to support rolling back a message in the case of a RuntimeException thrown from the listener.

[weston.price]

In other words, it's a *hack* to support the strange requirement of redelivery in the case of a BMT or NotSupported onMessage.

[adrian.brock]

No this is for CMT (and BMT/NotSupported with madness=true :-).

The correct protocol is last resource gambit (assuming MDB uses DB):

1) Prepare DB (vote ok)
2) Commit JMS (session.commit())
3) Commit DB (two phase if 2 works otherwise rollback)

The current protocol for nonXA JMS is "transaction observer" - which is much
weaker that LRG, we can't stop the DB from committing when jms doesn't commit.

tx.commit();
if (committed)
 session.commit();
else
 session.rollback();

[adrian.brock]

We currently print a warning about this at deployment time:

 else if (destination instanceof Queue && con instanceof XAQueueConnection)
 {
 xaSes = ((XAQueueConnection)con).createXAQueueSession();
 ses = ((XAQueueSession)xaSes).getQueueSession();
 }
 else if (destination instanceof Topic && con instanceof TopicConnection)
 {
 ses = ((TopicConnection)con).createTopicSession(transacted, ack);

HERE

 log.warn("Using a non-XA TopicConnection. " +
 "It will not be able to participate in a Global UOW");
 }

[weston.price]

Ok, this will change things somewhat as we need to

1)Wrap with some new LocalXAWrapper that can use the Local JMS transaction API where appropriate.

2)Enlist

In some ways it will make the code cleaner being that everything will be hidden behind the wrapper and the LocalTxDemarcation strategy stuff can pretty much dissapear.

[weston.price]

Right, but that's for the older version (AFS/StdServerSession) and is basically giving a warning about using non XA. The JCA adapter simply assumes that if you are not using an XAConnectionFactory, or you have chosen the madness option (ie BMT, CMT/NotSupported) that the local API will be used solely to support redelivery.

However, the problem I see is that the interceptor will suspend the transaction prior to onMessage being invoked in the case of BMT and NotSupported. As result, the DB work being done is not going to effect the overall outcode of the Tx because the underlying XA connection will never be enlisted.

[adrian.brock]

Yes, that is why it is madness=true.

You are back to "transaction observer" semantics for BMT/Not Supported.

[adrian.brock]

You are back to "transaction observer" semantics for BMT/Not Supported.

That is the UserTransaction can quite happily commit, but then the MDB
throws an NPE afterwards. We happily rollback the delivery.

Equivalently, the MDB happily commits the UserTransaction but we later find we
can't commit the jms session.

[adrian.brock]

Happy as in "Happy Gilmore" - oblivious :-)

[weston.price]

LOL!!!!!

[tobias]

Given the current implementation in 4.0.5, which of the datasources have to be XA aware to get proper transaction semantics with the JMS-DS and the DS a MDB might write to?

Is having the JMS-DS as a XA-DS enough? Or only is having the DS the MDB writes to XA aware enough? Or do both need to be XA-DSes ?

[adrian.brock]

Tobias your question is both offtopic and an FAQ
(the datasource connection used by JBossMQ/JBoss Messaging does not use the same
transaction context as the application so XA is irrelevant. It is always local 1PC semantics).

It is also not a development question. If you want to ask for help, use the user forums
as described at the top of this forum.