On Fri, 1 Jul 2005, Oliver Jowett wrote:
Heikki Linnakangas wrote:
branch id: Branch Identifier. Every RM involved in the global
transaction is given a *different* branch id.
Hm, I am confused then -- the XA spec definitely talks about enlisting
multiple RMs in a single transaction branch.
Can you explain?
I oversimplified a bit. The TM *can* enlist multiple threads of control (=
connection in JTA) to the same transaction branch. That's called
"tightly-coupled threads", and they should then be treated as one
local transaction in the RM. The calls will look like this:
conn1.start(xid1, TMNOFLAGS);
...
conn2.start(xid1, TMJOIN);
...
conn1.end(xid1, TMSUCCESS);
...
conn2.end(xid1, TMSUCCESS);
connX.prepare(xid1);
connX.commit(xid1, false);
conn1 and conn2 must share locks and see each others changes. They
mustn't deadlock each other. The JDBC driver can implement this in a very
straight-forward way by using the same physical connection for both conn1
and conn2. Note that there's only one prepare, and it can be issued using
any connection.
The other possibility is called "loosely-coupled threads". In this case
the calls look like this:
conn1.start(xid1, TMNOFLAGS);
...
conn2.start(xid2, TMNOFLAGS);
...
conn1.end(xid1, TMSUCCESS);
...
conn2.end(xid2, TMSUCCESS);
...
connX.prepare(xid1);
connX.prepare(xid2);
connX.commit(xid1, false);
connX.commit(xid2, false);
xid1 and xid2 can belong to the same global transaction, but different
branches. The RM doesn't need to care both branches belong to the same
global transactions, xid1 and xid2 can be treated just like any random
two transactions. They can deadlock each other, and they won't see each
others changes before commit. This can be implemented in the JDBC driver
by using two physical connections.
So the example given earlier in this thread, with one transaction branch
but two prepare-calls makes no sense. The RM should throw an exception
if the TM calls start twice with the same XID, and TMJOIN flag is not
given. One transaction branch maps in 1:1 fashion to one RM local
transaction.
I hope this helps...
- Heikki
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
