-
15. Re: JBossTS/JCA Recovery work for JBoss 4.2
Technically, in that scenaior the JCA/JMS adapter is supposed to provide the recovery mechanism via the
XAResouce[] ResourceAdapter.getXAResources(ActivationSpec[])
method.
This is still TODO on my list to implement for our JMS/JCA adapter
Ideally if an AppServer supports recovery it should call into this method after a crash and query the ResourceAdapter for the XAResource --> ActivationSpec (those specs that were deployed at the time fo the crash) mappings. From the XAResource they can obviously get the outstanding recovery work.
I think the miscommunication is that Tim is thinking solely from the JMS, non EE perspective...at least that's what I can gather. -
16. Re: JBossTS/JCA Recovery work for JBoss 4.2
I think you guys are thinking in purely JEE terms, in which case you are probably correct.
But what abou people who use JBoss as an all purpose service hosting container and aren't doing JEE - it would nice for them to be able to use recovery too.
For instance, JBM has a messaging bridge - which can run standalone in basically a stripped down version of JBoss. The bridge creates connections to other jms servers, and (depending on QoS required) consumes and send messages from one server to the other in a JTA transaction.
No JCA is used here, but we need recovery. So far we have done this by implementing our own XAResourceRecovery.
And you can imagine many more cases where people implement their own non JEE services which do stuff with XA not using JCA.
So, yes, I admit that from inside the JEE app server, all XA stuff should be done via JCA, but should we limit ourselves to that?
Why not abstract out the recovery stuff to another service which can be used by both JCA and anyone else? -
17. Re: JBossTS/JCA Recovery work for JBoss 4.2
For instance, JBM has a messaging bridge - which can run standalone in basically a stripped down version of JBoss. The bridge creates connections to other jms servers, and (depending on QoS required) consumes and send messages from one server to the other in a JTA transaction.
How stripped down? I would be interested to see how you got rid of JCA being that, without it, JBoss typically won't run (at least all those parts of the code requiring JDBC access). I am assuming that your JMS implementation is using a persistence store is it not? Are you managing your connections yourself, do you rely on JBoss to do this? If the latter..well...I hate to be the bearer of bad tidings... ;-)
So, yes, I admit that from inside the JEE app server, all XA stuff should be done via JCA, but should we limit ourselves to that?
On the 'Design of JCA on JBoss' forum we will.
Why not abstract out the recovery stuff to another service which can be used by both JCA and anyone else?
Because this is what the SPI contract of JCA already provides to a ResourceAdapter, ResourceManager, Application Server and Transaction Manager. Again, this is in the context of JBoss 4.2 and what needs to be done to finish this work. Not JBoss5 or later. If you want, please feel free to start another thread to that end.