JBossDeveloper

Andy Taylor wrote:

 

That's cool! However, how am I supposed to provide my implementation of TransactionManagerLocator to the HornetQ resource adapter? If I understand it correctly, your default implementation is the only place where the dependency on the JBoss way of locating TransactionManager is, correct?

you implement a class with a method that returns a TM and set transactionManagerLocatorClass and transactionManagerLocatorMethod properties on the resource adapter

That's what I am doing for AS7 integration to be able to locate its transaction manager. But, in this locator impl, I end up doing a JNDI lookup on "java:/jboss/TransactionManager" (I also had to modify hornetq-ra.jar MANIFEST.MF to be able to access the AS7 org.jboss.as.messaging module that contains the integration code)

I am not up to date on other app server but it'd be worth to move that JNDI lookup *inside* the HornetQ RA so that the user would have only to set the JNDI name to lookup the app server's TM. This is less involving than to ask them to write a specific locator + make it available on their app server deployments.

jaikiran pai wrote:

 

Jeff Mesnil wrote:

 

I am not up to date on other app server but it'd be worth to move that JNDI lookup *inside* the HornetQ RA so that the user would have only to set the JNDI name to lookup the app server's TM. This is less involving than to ask them to write a specific locator + make it available on their app server deployments.

I am not 100% sure but I think the spec doesn't mandate that the transaction manager be bound to JNDI, which means that moving this lookup within the HornetQ RA wouldn't be a good idea for portability.

You're right. iirc, only the UserTransaction must be bound to JNDI. However most app servers also exposes their tm too.

I don't see a portable way to have HornetQ get a reference on TM. However if we can  make it less involving, we should.

E.g. if a weblogic user wants to access HornetQ server, what would he prefer?

1. set a ActivationConfigProperty   "transactionManagerLookup" => "weblogic.transaction.TransactionManager"

or

1. write a locator class which does a JNDI binding (or something else specific to the app server)

2. add this class somewhere in the build & deployment process

3. still set ActivationConfigProperty to be able to instantiate and call the locator

4. do some app server magic to be able to call the locator from the deployed RA (eg to deploy the RA in AS7, we must add AS7 org.jboss.as.messaging module to the jar manifest)

After spending 1 week working on the RA, you could guess which solution I prefer

Andy Taylor wrote:

 

yes, but how would you propogate it from the activation spec to the transaction manager?

 

ie.

 

activationConfig = { @ActivationConfigProperty(propertyName = "transactionTimeout", propertyValue = "5000")  }

 

on the MDB

I don't understand this. Surely this transactionTimeout is for our XA resource, not for the TM.

E.g. what if the TM transactionTimeout is shorter, why do we chose to override it with our longer transactionTimeout?

Our responsibility is "only" to set the tx timeout on our XA resource. Looking at the code, it looks we're not doing that.

In HornetQResourceAdapter.createSession(), we do *not* set the transactionTimeout on the created ClientSession (which is our XAResource).

Isn't that the bug? We set it on the TM because it's not set properly on our XAResource?

Andy Taylor wrote:

 

The TM always calls setTimeout on the xa resource with its own default so the hornetq default or the MDB propert get over ridden.

For the record (and to close the discussion), we talked to the JBoss TS guys on IRC and indeed, our TM does set the XAResource's tx timeout when it enlist the xares.

Setting a tx timeout when the MDB is activated can be done only by setting it on the TM, not on our own xares...