On Tue, 30 Aug 2011 00:17:19 +0300, Vlad Khorsun
hv...@users.sourceforge.net wrote:
The XA semantics are a bit complicated, but essentially the database is
a
Resource Manager (RM), and a distributed transaction is assigned an Xid
by
the Transaction Manager (eg in the case of JavaEE it could be
Look also at isc_reconnect_transaction() API which allows to
re-connect to the in-limbo
transaction at recovery phase and finally commit or rollback it.
As far as I have seen, this is already done in Jaybird.
Very good.
So the commit can
be done from any connection, but what
On Sun, 28 Aug 2011 18:20:31 +0300, Vlad Khorsun
hv...@users.sourceforge.net wrote:
Certainly, we can make API look like we _do_ join a new attachment to
an
existing distributed transaction. To do so we just start new
transaction
in API call internally (need to know TPB...) and join it with
The XA semantics are a bit complicated, but essentially the database is a
Resource Manager (RM), and a distributed transaction is assigned an Xid by
the Transaction Manager (eg in the case of JavaEE it could be the
application server). If I read the spec correctly, it is expected that a
Look at isc_prepare_transaction2() API. It could attach *any*
application-specific
message to the local transaction before actual commit. TM could pass XID +
something
to identify this part of distributed transaction into
isc_prepare_transaction and later read
this info back from
On Mon, Aug 29, 2011 at 5:57 PM, Vlad Khorsun
hv...@users.sourceforge.netwrote:
Another issue here is that when a non-recoverable error
happens (e.g. request synchronisation error),
Hmm... is it unrecoverable error ? BTW, request synchronisation error
could happen only
at fetching
Wouldn't it be better to join a new attachment to an existing
distributed transaction?
No. Attachment *itself* can't participate in distributed transaction. At
least
not directly. Transaction of this attachment - can. Just understand:
attachment
*is not a* transaction.
28.08.2011 15:52, Alex Peshkoff wrote:
Certainly, we can make API look like we_do_ join a new attachment to an
existing distributed transaction. To do so we just start new transaction
in API call internally (need to know TPB...) and join it with existing
distributed transaction.
What
On 28-08-2011 11:51, Dimitry Sibiryakov wrote:
28.08.2011 15:52, Alex Peshkoff wrote:
Certainly, we can make API look like we_do_ join a new attachment to an
existing distributed transaction. To do so we just start new transaction
in API call internally (need to know TPB...) and join it with
28.08.2011 15:52, Alex Peshkoff wrote:
Certainly, we can make API look like we_do_ join a new attachment to an
existing distributed transaction. To do so we just start new transaction
in API call internally (need to know TPB...) and join it with existing
distributed transaction.
What
I am currently going over the XA implementation in Jaybird, and this
prompted some questions regarding transactions, connections and
two-phase commit in Firebird.
First of all: are transactions associated with the connection that
created it, or is it possible to 'share' the same
11 matches
Mail list logo
