UOW port to JCA adapter for JBAS-3183

[weston.price]

I am porting the StdServerSession/StdServerSessionPool code changes in HEAD and I had a few questions.

To support the code I need to figure out a way to get the XidFactory into the JmsServerSession. The TransactionManager is no problem because I can have the JmsActivation look him up from JNDI. However, the XidFactory is not bound by default. Rather than casting the TM to get the XidFactory or trying to look up the XidFactory MBean directly (wanting to keep JMX out of the adapter), I thought maybe the approach would be to have the XidFactory service bind itself into JNDI. At that point, it's the same process as looking up the TransactionManager.

The other approach would be to use the XidFactoryImpl directly, but I don't like the idea of this.

Other alternatives would be to create a TransactionManagerProviderAdapter thing, on the same level as the JNDIProviderAdapter.

Suggestions?

[adrian.brock]

The XIDFactory is a red-herring.

It is only used when it is configured with an XAConnectionFactory
and it knows it is going to eventually use 1PC, i.e. there will
be no other resources in the transaction.

This will be true for BMT or CMT/NotSupported.

In this case, it optimizes away the JTA transaction and drives
the "transaction" itself.

All it needs is a mechanism to generate unique XIDs
so it can control the XAResource.

Using the XIDFactory from JBossJTA is one mechanism,
but not necessarily the cleanest, especially when
we are moving to JBossTM for JBoss5 anyway.

[adrian.brock]

Equally, it could just create a real JTA transaction anyway.
For 1PC these have very little overhead.

[weston.price]

Using the XIDFactory from JBossJTA is one mechanism,
but not necessarily the cleanest, especially when
we are moving to JBossTM for JBoss5 anyway.

Right, which caused me to think about this prior to using this mechanism.

[weston.price]

Equally, it could just create a real JTA transaction anyway.
For 1PC these have very little overhead.

This would seem to be the best approach to me since we wouldn't have to rely on the 'useLocalTX' flag and just create a transaction under any circumstance. It definitely would make all of this cleaner.

[adrian.brock]

While you are in there, can you also implement this feature?
http://jira.jboss.com/jira/browse/JBAS-3321

This only applies for CMT/Required (for other types the delivery
transcation gets suspended anwyay).
You can find the code for other EJBs in org.jboss.ejb.plugins.TxInterceptorCMT

[weston.price]

Why not? As long as I have the 'patient open'...so to speak.

[weston.price]

So, eliminating the XIDFactory makes this cleaner, but giving the JmsServerSession still requires the TransactionManager. My plan is to have the JMSActivation look this up via JNDI and provide it to the JmsServerSessionPool.

Obviously when I can *finally* get around to going back to real work and not IBM support we can do this differently.

[adrian.brock]

Are you talking about the JMS inflow?
I thought you were talking about the old server session pool.

Making a resource adapter depend upon a jndi lookup is not very good.

If you want to do something non-portable, I'd rather you allowed
the JBoss BootstrapContext (RARDeployment) let you do a
getTransactionManager().

e.g.

-RARDeployment implements BootstrapContext
+RARDeployment implements JBossBootstrapContext

public interface JBossBootstrapContext extends BootstrapContext
{
 TransactionManager getTransactionManager();
}

TransactionManager tm = ((JBossBootstrapContext) bootstrapContext).getTransactionManager();

In fact, as it currently stands, you can do getXATerminator()
and cast it to a TransactionManager, but that is a different story. :-)

[adrian.brock]

But even that is not clean.

The fundamental issue is that some JMS impls don't support
using the normal JMS API from an XAConnectionFactory,
so you have to drive the XAResource even when you know
a simple jms session.commit()/rollback() would be better.

[weston.price]

Yeah, I wanted to avoid casting anything. But if you are ok with using the JBossBootStrapContext to do it, I am fine with that as well. I was just thinking that if we are already looking up stuff in the JmsActivation via JNDI it would make sense to do the same for the TransactionManager as well.

Casting the Terminator might actually be the lesser of the evils being that we already have that guy via the adapter. Only the code within JmsServerSession would have to change.

[adrian.brock]

It's not the JNDI lookup per-se, but what you are looking up.
It should really be restricted to only lookup admin objects.

In fact, it would be safe to use the org.jboss.tm.TransactionManagerLocator.
We plan to turn this into a portable mechanism to retrieve
the TM implementation for each platform.