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  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [PATCHES] Users/Groups -> Roles
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: [PATCHES] Users/Groups -> Roles