Support for multiple TransactionManagers?

[andreas_austing]

Hello there,

based upon ObjectWebs JASS Project I rewrote the (old) JBoss TransactionManager. My intension is to switch between different Transaction-Managers and different Transaction-Concepts. For example in a future version of the project, it may be possible to dynamically switch between the ACID-based TransactionManager and the ONT-based one (if it makes sense for a special scenario - not your bank account :-) ).

I see no bigger problems to switch between a JTA/ONT-TransactionManager.
- But how can i configure multiple JTA-based TransactionManagers?
- How can i tell 'the application server' which JTA-TransactionManager to use?
- Where makes the 'application server' the lookup for the TM to enlist the resource.
- Is it principal possible, or is it too complex?

I would be grateful for your information.
Andreas.

[andreas_austing]

Concretely I mean, if it does make sense to refactor the support for multiple TM's (project time: two month to go). If yes, some informations about an 'entry point' would be useful for me.

I'd also like to discuss the question, if it makes generally sense to switch the 'transaction concept'. Possibly based on special rules which make a desicion by collected sensor data (e.g. lock conflicts on a database).

Thanks
Andreas.

[marklittle]

"andreas_austing" wrote:
Hello there,

based upon ObjectWebs JASS Project I rewrote the (old) JBoss TransactionManager. My intension is to switch between different Transaction-Managers and different Transaction-Concepts. For example in a future version of the project, it may be possible to dynamically switch between the ACID-based TransactionManager and the ONT-based one (if it makes sense for a special scenario - not your bank account :-) ).

I see no bigger problems to switch between a JTA/ONT-TransactionManager.
- But how can i configure multiple JTA-based TransactionManagers?
- How can i tell 'the application server' which JTA-TransactionManager to use?
- Where makes the 'application server' the lookup for the TM to enlist the resource.
- Is it principal possible, or is it too complex?

I would be grateful for your information.
Andreas.

I'm assuming you're not talking about dyanmic changes, i.e., during the execution of a transaction? That would be a really bad idea in general, for all sorts of different reasons. As one of the original authors of the OMG Activity Service and JSR95, I haven't come across a need to do that (so far).

[marklittle]

"andreas_austing" wrote:
Concretely I mean, if it does make sense to refactor the support for multiple TM's (project time: two month to go). If yes, some informations about an 'entry point' would be useful for me.

I'd also like to discuss the question, if it makes generally sense to switch the 'transaction concept'. Possibly based on special rules which make a desicion by collected sensor data (e.g. lock conflicts on a database).

Thanks
Andreas.

Don't go there! It's a nice idea from an academic perspective, but it won't fly in the real world. All transaction deployments I know (using ACID or extended transaction models) have started from an architectural understanding of the need for "transactionality" within the application. Semantic information is often extremely important when you look at different extended transaction models. Switching between one or another at runtime to then execute over the same application and its data, is extremely complex. It's often a lot better (i.e., easier) to provide the user with a suite of transaction implementations and let them statically pick and choose. If they get it wrong, then they can rebuild. OK, it doesn't sound as nice as doing it dynamically at runtime, but it's a lot more practical and a lot less work for you.

[andreas_austing]

I'm assuming you're not talking about dyanmic changes, i.e., during the execution of a transaction? That would be a really bad idea in general, for all sorts of different reasons.

No, during a transaction, it would be really a bad idea. But lets assume a simple data-import scenario. When the system is under heavy load, it may be useful to switch the transaction-concept from ACID to ONT to relax the isolation-property (Only for new transactions). The import-process may possibly be faster (only an assumption).

The next idea was to do something similar with different implementations of JTA-TransactionManagers - each of them have different characteristics (ArjunaTS / JBoss TS). For some Apps it would possibly make sense to switch to a faster TM but with less recovery functionalities?!

Only an idea for reseach purposes. Or is it a really so bad?

Andreas.

[marklittle]

So JBossTS (and Microsoft's Indigo transaction service) already do much of this: starting off with a lightweight coordinator implementation, only add a log when needed, supporting lightweight participants (those that don't need durability and only isolation/atomicity).

I suppose from a research perspective it would be useful to look at how the Activity Service could be used to accomplish the same thing.

[andreas_austing]

Ok, thanks for the clarification.