db transactions spanning multiple JVMs with JTA
for my framework I need a way to have a single transaction span multiple JVMs.
Here's what I'm working on:
It is going to be a diustributed plugin framework which will be able to run with just J2SE. I have the basics done, I can load plugins based on a XML config file. The plugins can be located anywhere, on any server. The core of the framework handles all the communication between the plugins, so when you code a plugin, you don't have to worry about where the other plugins you are calling are located.
The problem I am now facing is that I need to have a transaction system that will let me group multiple plugins in the same transaction. But seeing how each plugin can potentially run in its own JVM, I need to figure out how to do this.
Everything I read online is that JTA is the way to do this. But all I can find are JTA examples that have a single JVM with multiple databases in a single transaction. This is not what I need, but I can't find any examples related to my use case.
If you guys could help me along, that would be great.
Wow this is so old but decided to reply anyways in case someone is faced with similar problem. I had a shopping cart application with instances of the same application running on several JVM's. Now, I had an external application that wished to insert into the shopping cart via a web service, and instantly redirect the user to the shopping cart to see what they've just inserted, and hence continue the checkout process. The problem is this: the web service call that inserts into cart would be handled by one shopping cart instance (i.e. JVM), but when redirected there's no telling which JVM would handle the display of shopping cart to customer. All the shopping cart instances shared one central cache. Because of delays in cache frefresh times (configured via cache entry timeout/expiration), most of the time customer would see an empty cart upon redirect. The problem was not the web service call to insert into shopping cart, but that the JVM handling the redirect to display shopping cart to customer did not yet have a cache that was synchronized with the DB. If you were to query the DB, the item would be there in the cart, yet cache for the JVM that handled the redirect was not up to date yet.
The solution was for the JVM that handles the redirect to flush its cache on the shopping cart Java object *only*. The API I was using did not provide a single method that would do all the steps necessary to make the flush happen, so I ended up combining several method calls into one, to provide a single unified method call to flush the shopping cart cache for me. The API I was using was ATG. Not sure if you've heard of it.
At any rate, a similar approach may be used for what you're trying to do.
Another solution that was floated around but not implemented was to keep the web service call and customer redirect on the same JVM. But the show stopper here is that, even if the web service call would return the JSESSIONID back to external app so that it'd know which JVM to send customer redirect to, this would *not* work. The reason is that a layer of load balancing servers determines which JMV handles the request. In other words the calling external app has no control whatsoever to determine which JSESSIONID handles a request. And I believe this is so because of security reasons. Imagine, hackers could bring down one JVM instance after the other by sending many request to a single JVM.
I hope this helps anyone faced with similar problem. Thanks.
Mark - By the way, what was the solution to your problem?
Last edited by joquijada; 05-21-2013 at 05:57 PM.
Reason: Many typos that would intrude responses intuitiveness.
By Amt_asc in forum Database
Last Post: 04-03-2009, 04:13 AM
By hazaraSp in forum ASP.NET
Last Post: 01-29-2008, 08:24 AM
By jezreaton in forum Java
Last Post: 01-27-2006, 01:01 PM
Tags for this Thread
-- Android Development Center
-- Cloud Development Project Center
-- HTML5 Development Center
-- Windows Mobile Development Center