Subject | Re: [IB-Architect] Re: Embedded Transactions |
---|---|
Author | Jim Starkey |
Post date | 2003-01-22T15:45:10Z |
At 11:49 AM 1/22/2003 -0000, Roman Rokytskyy <rrokytskyy@...> wrote:
difficult to discuss with clarity. If a "nested transaction" is
an inner transaction whose updates, if committed, are visible
to other inner transations of the same outer transaction, but
are not visible to other independent transaction until and if
the outer transaction is committed, then Interbase/Firebird
has (though possible had) them. In any case, I implemented them
at least a dozen years ago.
The trick is very simple, and is done with transaction bookkeeping.
An inner transaction is handled by a distinct transaction id like
any other transaction. When "committed", however, it is left
"active" in the database but "pseudo-committed" to it's parent
transaction. The rest of the work is bookkeeping. An indepdent
transaction pays attention onto to the state of the transaction
as per the TIP. Transactions belonging to the outer transaction
look a little harder to compute relative state. When the outer
transaction commits, it and the inner transactions are committed
with a three phase commit.
What has happened to the feature after Interbase left home to find
its own place in the world I cannot say.
Jim Starkey
>There doesn't seem to be established terminology, so it's a little
>Hard to say. I made some googling and found that the concept
>of "embedded transaction" seems to be Compiere's "invention".
>Unfortunatelly they do not disclose this concept (patent pending?).
>People seem to agree that most likely they mean "nested
>transactions". As far as I know nested transactions are not in the
>feature list for the Firebird 1.5 and Firebird 2.0.
>
difficult to discuss with clarity. If a "nested transaction" is
an inner transaction whose updates, if committed, are visible
to other inner transations of the same outer transaction, but
are not visible to other independent transaction until and if
the outer transaction is committed, then Interbase/Firebird
has (though possible had) them. In any case, I implemented them
at least a dozen years ago.
The trick is very simple, and is done with transaction bookkeeping.
An inner transaction is handled by a distinct transaction id like
any other transaction. When "committed", however, it is left
"active" in the database but "pseudo-committed" to it's parent
transaction. The rest of the work is bookkeeping. An indepdent
transaction pays attention onto to the state of the transaction
as per the TIP. Transactions belonging to the outer transaction
look a little harder to compute relative state. When the outer
transaction commits, it and the inner transactions are committed
with a three phase commit.
What has happened to the feature after Interbase left home to find
its own place in the world I cannot say.
Jim Starkey