Hello,
I have a setup like this:

2 JVMs on 2 different servers. No J2EE container on either. I now need to do a two phase commit with a transaction spanning the JVMs on both servers.

example:
I start a transaction on server A. Here I insert something into the database. The, I pass the ID inserted to server B, which inserts something else with a foreign key relation to the record inserted on server A. I only want to commit if both the action on server A and server B are successful.

I this possible with Hibernate?
I was personally thinking of setting the flushmode to manual on both servers and then making a call to flush, and if the flush on both machines was successfull, make a call to commit. But I'm not sure if this would work.

Mark

Hi,

two phase commit requires integration with JTA (instead to using JDBCConnetionFactory).
I recently wrote an article for how to integrate Hiberntate with JTA outside J2EE application server:

http://community.jboss.org/wiki/ImplementingstandaloneJPAJTAHibernateapplicationoutsideJ2EEserverusingInfinispan2ndlevelcache

N.B.: In your concrete case, you actually don't need the 2 phase commit, because you just have to handle 1 single database (= 1 (XA)Resource).
What you require are distributed transactions:
JTA should allows you to create a global Transaction on JVM1 and then commit it on JVM2.
I personally never did implement something like this, but according documentation it should be possible.

Looking very much like what I need. I am going to be looking into this over the next few days, but I am particularly interested in the JBoss example. As for the single database issue, I would think that it would be possible to treat is as multiple databases without to much trouble.

Oh, and if anyone is interested, I am using this for my distributed plugin framework. I am trying to get the transaction manager in there setup so it isn't coupled to a distinct database connection framework though, so it may need a bit of tweaking on my part, probably by using code injection to allow the injection of the transaction manager of your choice or something like that.

Hm, you mean you want handle it with 2 different XA-Resources referring the same database?
Then you have to access at least the database with UNCOMMITTED_READ isolation on the 2nd JVM,
otherwise you cannot see the uncommited record.
Anyway I fear that you will face some other troubles with this approach, as OPEN/XA it is not conceived for defining
2 different XA-Resources referring one unique resource.

That's what I am afraid of myself. Which is why I'm currently also looking for someone with more experience in this area then me to come to the rescue. No luck so far though.

Ideally what I would want is for the two JVMs to share the same hibernate session and transaction, with the same resources. So that when I update a record in one JVM, the other JVM will also see that change, with or without a commit.

From what I read about 2nd level caching is that any uncommited mutations I make on one JVM aren't sent to the cache on the second jvm untill I commit, is this correct?

Also I have the impression that the community using OPEN/XA with real distributed transactions over different JVMs
is really small.


Hm, slowly I begin to doubt if hibernate or better JDBC allows this at all: obtain a connection to an already open-transaction ?
I believe that distributed transactions protocol provides only the possibility to issue the commit on the global transaction out from another JVM, but not to share JDBC-connections over different JVMs.
So probably you have really to use 2 separate XA-resources (one for each JVM) sharing the same database.



If you properly use JBossCache (Infinispan) as 2L cache with JTA-integration then this is correct.
If you use other 2L cache implementations like EHCache, then I don't know the answer.


N.B.: Given all troubles, I would seriously re-evalutate your first idea
-simply call flush for simulating the first phase commit on both sides using dirty-read isolation level and no version control.
It is not 100% sure that the commit afterwards succeds, but usually it does if defining constraints properly on db.
The communication between the 2 JVM you could realize through JMS or something other.
This allows you to get rid of the complex JTA and OPEN/XA approach, which is not easy to implement outside an application server with(out) transaction service.

I am currently working on the manual flush area. The only thing I am worried about is that the second JVM won't see the changes made by the first.
As for the dirty read isolation level and no version control, I'm not sure what you mean by that or how I would set that up.

Another way I was thinking of was implementing a central cache that would be transaction aware. This would probably solce the issue, but be very complex indeed to implement.

If you use dirty_read (aka noncommited_read) isolation level, then you should able to see changes made by others once they have flushed.
You can configure the isolation via

property.



You mean a 2L cache which replicates its data to another cluster node a soon it is flushed (not yet commited)?

If you use JBossCache as hiberante 2L-cache implementation improperly without jta-integration, then you have such behavior.
Because using JBossCache improperly without jta-integration means, that each cache interaction is handled as atomic action. So your cache is synchronized immediately with the flush.

N.B.: This improper use is rather dangerous: if you flush and then rollback, then your 2L-cache keeps stored uncommited data!
(without jta-integration JBossCache don't get notified about the commit/rollback events)
In such case you must evict manually all relevant data from 2L cache.

Ok, so if I understand, your suggesting to use JBoss 2L cache and set the hibernate.connection.isolation to false?

It may work, but it is surely not the way which hibernate it was designed for.
What I suggest is to rethink your business design, allowing to create and attach informations to objects in different transactions handling eventual rollback actions programmatically with delete commands.
Your originally idea is IMHO a little bit weird.

Yeah, I did that already. Didn't feel comfortable with this dirty solution. Now I'm following a solution more along the line of J2EE-servlets. Each Plugin runs in a transaction sandbox, so each plugin performs a commit or rollback before returning.

This may have some unforeseen results as well, but that will have to be fixed by decent logging and application management.
I will remove the transaction manager tomorrow after which I will be releasing a new version of the framework for you to try out. There is a Javadoc and the beginning of a wiki. With that you should be able to try out the framework for yourself. I will be working on test classes as soon as I can find the time and can figure out what kind of test classes would work.

The link is: http://sourceforge.net/projects/pffj