| Subject | Re: Two phase recovery |
|---|---|
| Author | Adam |
| Post date | 2007-12-03T02:29:22Z |
--- In firebird-support@yahoogroups.com, "Fabiano Bonin"
<fabianobonin@...> wrote:
http://en.wikipedia.org/wiki/Two-phase_commit_protocol
When a transaction spans multiple databases, it needs to
commit/rollback as one. But the problem is that communications between
the databases may fall to pieces even during the commit phase. The two
phase commit protocol basically adds another state to a transaction
which Firebird calls limbo. It means that it is not active (we know
that much), but we don't yet know whether it is rolled back or
committed. If the connection between the databases is severed at this
point in time, the transaction is left in limbo.
Ann's response makes sense.
In the first phase, all the databases involved must agree to commit.
If one of them did not agree to commit, then the resolution is easy
and automatic. Everyone must rollback.
If everyone did agree to commit, but the connection was broken before
they could be told, then the resolution is easy and automatic.
Everyone must commit.
But notice that Gfix must be able to contact each of the databases
involved in the 2PC. If it can't, then you have problems. How can
Firebird possibly know that some database that can't be contacted
didn't roll back? It needs your help to decide what *you* want it to do.
Adam
<fabianobonin@...> wrote:
>sometimes
> > Fabiano Bonin wrote:
> > > Hi all,
> > >
> > > Why sometimes when doing two phase recovery gfix ask for what
> > > operation should be done (commit, rollback ou neither) and
> > > it doesn't ask anything?http://www.ibphoenix.com/main.nfs?a=ibphoenix&l=;KNOWLEDGEBASE;ID='217'
> >
> > If all participants in the original transaction are available,
> > Firebird will determine on its own whether the transaction should
> > be committed or rolled back. If any sub-transaction has not prepared,
> > then everyone rolls back. If everyone has prepared, everyone
> > commits. If anyone can't be found, then gfix has to ask.
> >
> > Do you really want to commit regardless of the state of the other
> > sub-transactions?
>
> Well, i don't know what to answer because all this sounds greek to me.
> Also i just started to use gfix for two phase recovery recently, when
> i discovered that just windows version works for this task.
> Up to now i had tried many times with linux version with no success,
> so i'm not used with this procedure.
> Is there some document i can study about it?
http://en.wikipedia.org/wiki/Two-phase_commit_protocol
When a transaction spans multiple databases, it needs to
commit/rollback as one. But the problem is that communications between
the databases may fall to pieces even during the commit phase. The two
phase commit protocol basically adds another state to a transaction
which Firebird calls limbo. It means that it is not active (we know
that much), but we don't yet know whether it is rolled back or
committed. If the connection between the databases is severed at this
point in time, the transaction is left in limbo.
Ann's response makes sense.
In the first phase, all the databases involved must agree to commit.
If one of them did not agree to commit, then the resolution is easy
and automatic. Everyone must rollback.
If everyone did agree to commit, but the connection was broken before
they could be told, then the resolution is easy and automatic.
Everyone must commit.
But notice that Gfix must be able to contact each of the databases
involved in the 2PC. If it can't, then you have problems. How can
Firebird possibly know that some database that can't be contacted
didn't roll back? It needs your help to decide what *you* want it to do.
Adam