I guess I need JTS because there are EJB calls inside the transactions that should be included in the transactions.
If it is better to use separate object stores for each Tomcat instances then I will set it up correspondingly. I thought having the RecoveryManager run in a separate process would remedy the mentioned problem of the datasources that must be configured in the global JNDI context.
I found that at the moment JTS is not activated at applications servers in general. (There are dozens of clusters; maybe some have JTS activated.) If this is a necessary prerequisite then it will be done.
Here is some background why I want to use propagated transactions: My team is responsible for a central order and fullfillment process. Customer orders come in via the front end. The process spans the writing of commercial records as well as provisioning the ordered products. The provisioning part is very heterogenous. The setup of products is triggered by submitting a JMS message, by web service calls, or by EJB calls. Ideally, all of these steps would be part of a single transaction.
> If this is a necessary prerequisite then it will be done.
If it's not clear to you that it's necessary, then you're in over your head. You do realise that if you switch the transaction managers in the app server, you'll take a performance hit for all the transactional apps running in them, even the ones that don't need JTS? It's not something to treat as a casual config tweak.
> Is it possible to have a single object store that is used by both Tomcat instances?
Yes. Not sure why you'd want to though.
> Should the RecoveryManager be run as a separate system service?
You must have exactly one RM per ObjectStore, so if you opt to run with a shared store then you have no choice but to run the RM out of process. I suppose you could deploy it into only one of the tomcat instances, but that's going to get really messy.
> I guess that if the RecoveryManager is run as a system service then the Tomcat instances must not start the RecoveryManager too.
> Must [the TransactionServer] service also be installed as a system service?
> I would prefer to configure the data sources not in the global JNDI context like the Tomcat integration example does. It would be better if each deployed war can bring its own data sources. The Tomcat integration example tells that it is important to use the global context because of recovery. However, if the RecoveryManager is a separate system process then this argument is no more relevant.
Running the RM out of process is not the only option. You could just as well use application lifecycle hooks to register/deregister an app bundled datasource with the in-process RM as the app is deployed/undeployed. It just leaves you with potentially lower availability.
Thank you for the information. I fear that I must dive a lot deeper in the transaction topic. I have a couple of more questions:
1. Are mixed environments (JTS only activated at some dedicated App-Servers) possible?
2. Can the TransactionServer service started by a Tomcat lifecycle listener similarly to the RM? Is there some example code? Should every Tomcat instance start a separate TransactionServer service?
3. Has using the TX-Bridge a similar negative impact like using JTS? We could switch some of our EJB calls into corresponding web service calls.
4. Using separate ObjectStores for each Tomcat instances seems the way to go. Could you please give some more information how application provided datasources can be registered with the RM. Why would there be a lower availability?
Thank you for your help!
> 1. Are mixed environments (JTS only activated at some dedicated App-Servers) possible?
huh? how is that a 'mixed environment'? It's just a bunch of independent app servers with different configurations. It's only meaningful to consider them as related in so far as they communicate with one another. In which case the question becomes: what protocol(s) do they use to communicate? e.g. as far as the transaction system is concerned a 'cluster' of app servers that only use shared web session store are actually independent, as that's completely orthogonal to the transaction system.
> 2. Can the TransactionServer service started by a Tomcat lifecycle listener similarly to the RM?
Sort of, although there is really no mechanism to 'start' the transaction system. You can configure it and you can use it, but it does not have an explicitly defined lifecycle. Or to put it another way: it starts on demand the first time you use it. Which BTW causes some interesting headaches in environments with multiple classloaders. In particular you probably want to initialize the transaction reaper explicitly in a defined TCCL, which I suppose could be viewed as 'starting' at least part of the system manually.
> 3. Has using the TX-Bridge a similar negative impact like using JTS?
No, although booting the web services stack will impose a startup overhead. And BTW what do you plan to use as the WS container in tomcat?
> Could you please give some more information how application provided datasources can be registered with the RM.
> Why would there be a lower availability?
Because you can perform recovery only whilst your app is available. For servers that deploy large or complex apps, this can add several minutes to recovery time following a crash, even assuming the crash is detected and the process restarted promptly.
add 1: Maybe is should reformulate my question: "Is it possible for a process using JTS transactions to call an EJB on an app server that has JTS not activated?"
add 2: Ok - so every Tomcat instance just calls TransactionReaper.create() in its lifecycle listener.
add 3: I planned to use CXF. The discussion at http://cxf.547215.n5.nabble.com/WS-Coordination-WS-AtomicTransactions-WS-MetadataExchange-td3216884.html seems to indicate that JBossTS can be made to work with CXF.
> Is it possible for a process using JTS transactions to call an EJB on an app server that has JTS not activated?"
sure. suspend the tx, make the call, resume the tx. Oh, wait, you meant *call an EJB with JTS transaction context propagation*. So, no.
> I planned to use CXF.
Good luck with that. Getting XTS to work in tomcat is nowhere near as easy as ripping out tomcat and using JBossAS instead.
Ok - you recommend using JBossAS and JBossWS.
Thank you very much for making things clearer.
If we take that way then we must migrate our Spring based application and exchange the CXF based <jaxws:endpoint/> and <jaxws:client/> configuration elements. Can JBossWS endpoints and clients similarly exported and imported in a Spring configuration running inside a war deployed in JBoss? Or should the JBoss-Spring-Deployer be used?