JBossDeveloper

Why dont i add a thread local for this setting that gets set at the beginning and will outlive the  rollback/end. I think its all called within the same thread?

I don't think it would work. The same thread will be reused later.

I was just looking at the code. There's a cleanup method on it. Can't we use it to determine when the Connection was closed? We shouldn't clear the isXA status until the clear is called.

Tim Fox wrote:

 

I assume you're talking about BMT here? Also, is this is an MDB?

 

(Some illustrative code would be good)

This is  about UserTransaction.. so it has to be BMT.

The first post has the code...

UserTransaction ut = sessionCtx.getUserTransaction();
ut.setTransactionTimeout(5);
ut.begin();

mc.receiveNoWait();

mc.close();
try
{
       Thread.sleep(10000);
}
catch (InterruptedException ignored)
{
}

// nothing here should be accepted since the transaction is expired (more than 5 seconds).

try
{
        MessageProducer p = s.createProducer(queue);
        Message m = s.createTextMessage("100");
        p.send(m);
}
catch (JMSException expected)
{
}

TX.end was clearing the state. I have removed that, tested and it works now.

https://jira.jboss.org/browse/HORNETQ-413

I cut a snapshot and integrated it on the application server, then I've run the TCK with this fix... This fix is breaking the TCK

There are quite a few tests that are doing this:

Connection  c = ....  Open the RA Connection ...

Session s = c.openSession(....)

MessageProducer p = s.openSession(....)

UserTransaction.beingTransa

UserTransaction.rollback();

p.send(...);

And expecting the message to be sent as non-transacted. In other words expecting the Connection to be clean after the rollback.

If we fix the above test, TransactionActiveUnitTestCase won't work any more.

We would need to be able to differentiate a Timeout and a regular rollback. Currently the TM don't make any distinction for us.. as a simple End(sucess) will be called prior to the rollback();

I will check on the legacy RA if they are doing any magic to make the distinction. Otherwise I guess we will need the TM to give us some way to distinguish the timeout ocurring.

My suggestion so far is the TM calling End(Failure) before the rollback.

The legacy adapter is solving this by checking the state on the transaction manager directly. I will see if I can implement something without adding new dependencies.

For reference this is the method from the old RA:

public void checkTransactionActive() throws RollbackException, SystemException
   {
      if (tm == null)
         throw new IllegalStateException("No transaction manager: " + ccmName);
      Transaction tx = tm.getTransaction();
      if (tx != null)
      {
         int status = tx.getStatus();
         // Only allow states that will actually succeed
         if (status != Status.STATUS_ACTIVE && status != Status.STATUS_PREPARING && status != Status.STATUS_PREPARED && status != Status.STATUS_COMMITTING)
         {
            if (status == Status.STATUS_MARKED_ROLLBACK && IGNORE_STATUS_MARKED_FOR_ROLLBACK)
               ;  // allow database access even though transaction is marked to fail 
            else
               throw new RollbackException("Transaction " + tx + " cannot proceed " + TxUtils.getStatusAsString(status));
         }
      }
   }

Our ResourceAdaptor don't have any reference to the Transaction Manager.

The only place the TM is accessed is through our activation code, where a bunch of reflection is done to setup the timeout of the transaction, if passed through activation.

We would need access to the TM through the ConnectionManager or anything global on the Resource Adapter to fix this issue.

Sure, I know.. it's going to be pluggable and optional.

If the TM is not available on the RA.. all will behave as it would behave now.

FYI I've added the plugin to locate the transaction manager on HornetQResourceAdapter and removed it from the Activation. The MessageHandler will be able to get the TransactionManager (if available) from the ResourceAdapter.

BTW: I've checked on my box and both the TCK and the AS testsuite are now passing with trunk. I'm just waiting the result from Hudson to have an official stamp and I will be able to cut a 2.1.1 release after that's confirmed.