On 09/20/2012 06:39 PM, Jason Greene wrote:
There really is no portable way to get at TransactionManager. However you should be able
to do it from a rar using a jndi lookup on java:/TransactionManager or
java:jboss/TransactionManager. IIRC the service dependency isn't a strict requirement
at that stage.
Otherwise to get at the ServiceContainer you should be able to use a ServiceActivator in
the RAR (requires a META-INF/services/* entry).
I have a patch where I use JNDI to get the TransactionManager.
But HornetQ RA also support auto recovery that needs access to the Tx's
RecoveryManager that is not exposed through JNDI.
I was looking for a general solution for this. Using a ServiceActivator might be it. Not
supporting AS7-specific features from a
deployed RA is another option.
BTW whats the main use case of this? The ability to use a different
version of a hornetq client?
No, the use case is to be able to use the RA to consume messages from a remote JMS server.
It should not be necessary to start a
local HornetQ server for that.
Note that the RA works fine as it is except for 2 edge cases (*autorecovery* and *tx
timeout* that requires access transaction
subsystem's services). The question is: when we deploy HornetQ RA in a standalone AS7,
do we want to support these 2 features or
not? These 2 features will not be supported when the RA is deployed on other app servers
in any case.
Looking at the forums links it seems we need to fix a few things in
our subsystem configuration. Is there a way we could not require a running server to
configure the pooled connection factory?
I think you are right, that's the cleanest solution.
Actually, the pooled connection factory should *not* have been put inside the hornetq
server, they are able to work without one
(it's similar to the JMS bridge with that respect).
However, this is a lot of configuration/code changes for small benefits (tx timeout or
auto recovery) that can be work around
having a local hornetq-server running (without any acceptors defined and open sockets, it
is harmless).
I am not convinced it is worth it. I'm much more of in favor to not change anything
(i'm lazy :) and keep things simple:
* if the RA is deployed as a standard RA => no AS7-specific features (e.g. auto
recovery)
* if the RA is used through the messaging subsystem => AS7 features are supported out
of the box
On Sep 20, 2012, at 11:09 AM, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
> I'm pretty much a noob when it comes to this RA, but this sounds
> architecturally odd to me.
It is odd. the JCA spec does not define a way to get a reference to the TransactionManager
from a RA for a good reason. It does
not make sense for a XAResource to require a ref to its TransactionManager.
HornetQ RA wants to do this to support a legacy feature (set the tx timeout on the MBD
activation spec). Our TM implementation
overrides the XAResource tx timeout with its own. The only way to let the MDB set a tx
timeout is to set it on the TM.
jeff
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/