Hibernate version:
2.1.4

Name and version of the database you are using:
Informix SE 7.x

Our application requires to do distributed transaction between 2 or more databases. I guess Hibernate can participate in a distributed transaction, but don't know. Can anyone please answer the following questions regarding this:


1. Should my database engine support distributed transactions?. For example my database Informix SE Engine should support Distributed Transactions in order to participate in dist. transactions?

2. Or is it enough if my JDBC driver support Distributed Transaction?

3. Does Hibernate support distrubited transactions?

First, talking to two data sources from within the same application VM is *not* "distributed in terms of needing distributed transactions. It would need JTA 2PC. Distibuted transactions are for scenarios where the transaction needs to encapsulate work on seperate VMs.

As long as the datasource at which you point Hibernate is all configured for JTA or distributed transactions and the calls into Hibernate are wrapped in that ongoing transaction: thats all thats needed.

I came across XA datasources. Do I have to use XA datasource in order to connect to 2 or more datasources that participate in a single transaction?

That depends upon the TransactionManager and ResourceManager you are using.

The point is that it does not matter to Hibernate. As long as the datasources it uses participate in the same JTA transaction, it will participate in the overall JTA transaction.

Talking to two datasources from the same VM such that the ACID transaction semantics are preserved is a Distributed Transaction.

Transaction propagation is ability for a transaction to encapsulate work on separate VM's and this is something most J2EE Transaction managers support.

That is simply not correct.

A distributed transaction is one in which a transaction needs to be coordinated between distributed transaction managers.

I don't understand what distributed transactions has to do with the number of client VM's. A single transaction manager in a J2EE app (one VM) can orchestrate a distributed transaction across two (or more) data sources as long as they're using an X/A driver.

For example the following code could be running in a single J2EE container using a single transaction manager and is a distributed transaction.

//start new user transaction.
userTX.begin();
ds1 = (javax.sql.DataSource)
initCtx.lookup("java:comp/env/jdbc/DB_1");
con1 = ds1.getConnection();

ds2 = (javax.sql.DataSource)
initCtx.lookup("java:comp/env/jdbc/DB_2");
con2 = ds1.getConnection();

// insert data into DB_1 using con1
// insert data into DB_2 using con2

-- userTX.commit(); //commits data in both databases

-- userTX.rollback(); //roll back data changes in both databases


What am I missing?

Sanjiv

But see your just throwing the term "distributed" in there. From the perspective of the transaction manager/coordinator, there is nothing distributed about this.

When talking about transaction managers the term "distributed transaction" means that they (the transaction manager) must coordinate amongst remote resource managers. In the situation you both are describing, the resource managers are *not* remote (even though the resources they manage might be). There is a difference.

The transaction manager is aware about the the transactions being distributed (more than one datasource invloved) and has to follow the 2PC protocol. Some J2EE transaction managers are smart and if they detect that there's only one datasource involved in the transaction, the carry out optimizations and avoid the overheard of redo logs etc involved in the 2PC protocol.

Back to your original description of use of distributed transactions, I'd like to see supporting material to describe distributed transactions in such a way.



My understanding is that "distributed" refers to the fact that the datasources involved in the transaction are distributed i.e. different. In other words no matter how transactions propagate in the client (same VM or multiple VM's), a transaction is never distributed if it involves only one datasource.

A search for "distributed transactions" came up with several results. Here's one link

http://www.databasejournal.com/features ... hp/1550951

Oracle is the best for distributed transactions - You can set databases (more databases) transparent to client - client see one databases and oracle 2pc work transparent and get data from any databases

for instance - you can have table A on database data1 and table B on database data2
You choose one database (it isn;t important which, btw data1) and make database link to
database data2 and then create synonym B for table B on database data2
After this you access to tables A and B normal with database data1 - for client A and B are on data1 - client can select,insert,update, delete etc and he think that exists only database data1

Databases data1 and data2 can be on same or different computers

regards