Subject | Re: [firebird-support] Transaction in limbo |
---|---|
Author | Mark Rotteveel |
Post date | 2016-07-19T10:40:21Z |
On 19-7-2016 12:14, Michael.Vilhelmsen@... [firebird-support] wrote:
single connection.
It just means that instead of doing an immediate commit/rollback, you
first prepare the transaction (which puts it in 'limbo'), and then
commit or rollback. Between the prepare and the commit/rollback you can
do other things. For example when participating in a distributed
transaction, you get a note from the distributed transaction manager to
prepare a commit, you prepare, you then signal to the manager that you
are ready to commit, and then wait for the manager to ask you to really
commit (all other participating transactions prepared successfully) or
rollback (one or more participating transactions failed to prepare).
The most common use case is distributed transactions, but nothing
prevents you from performing a 2-phase commit without participating in one.
So without knowing your application etc, it is impossible to tell what
might be causing transactions to go in limbo, except for the theoretical
causes.
So, what kind of applications do you have, in what language, does it use
isc_prepare anywhere, or (for example in Java) an XADataSource?
Mark
--
Mark Rotteveel
> As I read about 2 phase commits, its about 2 databases. We do not useNot really, two-phase commits can also be applied to a single database,
> more than one
single connection.
It just means that instead of doing an immediate commit/rollback, you
first prepare the transaction (which puts it in 'limbo'), and then
commit or rollback. Between the prepare and the commit/rollback you can
do other things. For example when participating in a distributed
transaction, you get a note from the distributed transaction manager to
prepare a commit, you prepare, you then signal to the manager that you
are ready to commit, and then wait for the manager to ask you to really
commit (all other participating transactions prepared successfully) or
rollback (one or more participating transactions failed to prepare).
The most common use case is distributed transactions, but nothing
prevents you from performing a 2-phase commit without participating in one.
So without knowing your application etc, it is impossible to tell what
might be causing transactions to go in limbo, except for the theoretical
causes.
So, what kind of applications do you have, in what language, does it use
isc_prepare anywhere, or (for example in Java) an XADataSource?
Mark
--
Mark Rotteveel