Re: 2PC transaction id
От | Barry Lind |
---|---|
Тема | Re: 2PC transaction id |
Дата | |
Msg-id | 03E7D3E231BB7B4A915A6581D4296CC601402130@NSNOVPS00411.nacio.xythos.com обсуждение исходный текст |
Ответ на | 2PC transaction id (Dave Cramer <pg@fastcrypt.com>) |
Ответы |
Re: 2PC transaction id
|
Список | pgsql-hackers |
>>> 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. In your example above couldn't conn1 and conn2 be running in two different JVMs? And thus your statement that 'the JDBC driver can implement this in a very straight-forward way by using the same physical connection' would not be true. I can't see a way for two JVMs (possibly on different client machines even) to share the same physical connection. --Barry
В списке pgsql-hackers по дате отправления: