Re: Heuristic rollback /commit
- From: Laimutis.Nedzinskas@xxxxxx
- To: "'oracle-l'" <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 8 Jun 2011 13:20:21 +0300
Wandering if this case can be covered by CAP (Brewer's) Theorem
( http://en.wikipedia.org/wiki/CAP_theorem )
We have a distributed system. We have to deal with all three:
Consistency (well, all nodes see the same data. In our case - for a given
transaction, all nodes see the same transaction metadata - commited or not)
Availability (we do not want to stop, lock, whatever)
Partition tolerance (message can be lost)
Am I wrong somwehere ?
Brgds, Laimis N
---------------------------------------------------------------------------------
Please consider the environment before printing this e-mail
From: "Jonathan Lewis" <jonathan@xxxxxxxxxxxxxxxxxx>
To: "'oracle-l'" <oracle-l@xxxxxxxxxxxxx>
Date: 2011.06.07 21:08
Subject: Re: Heuristic rollback /commit
In principle, no.
Two phase commit (2PC) means a commit turns into: "everyone prepare" --
"everyone commit", which gives you a few options:
If the co-ordinator crashes before anyone prepares then every database
needs a
simple process rollback, and everyone else is going to go read-consistent
on any
changes.
If the co-ordinator crashes after only prepares then the databases that
have NOT
received a call to prepare will go into simple process recovery and
everyone
else is going to go into read-consistency on any changes, while the
databases
that HAVE acknowledged the prepare won't know whether anyone else has
received a
commit - so they have to go into an indeterminate state that has to be
corrected
manually; which they are in this state, the behaviour of other processes
QUERYING the changed blocks is dependent on the version of Oracle and
technology
in use - they may hang waiting in mode 4 on the TX lock of the prepared
transaction, they may assume that they should go read-consistent.
If the co-ordinator has prepared all, and committed some - then the
prepared-only database will go into an indeterminate state that has to be
manually corrected. (It's possible that if they can talk directly to the
other
databases then there is an automatic recovery option that will allow them
to
recognise that they should be committed - but that might be a bit of gossip
that
I picked up and never checked.)
It IS possible, though, for the person doing the cleanup to do the wrong
thing
by (e.g. force committing parts of a distributed transaction that should
have
been forced rollback).
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
----- Original Message -----
From: "Petr Novak" <Petr.Novak@xxxxxxxxxxxx>
To: "'oracle-l'" <oracle-l@xxxxxxxxxxxxx>
Sent: Tuesday, June 07, 2011 3:35 PM
Subject: Heuristic rollback /commit
Hi,
if during XA transaction the TransactionManager crashes, what happens on
the
participating Oracle DBs ?
Would these DBs recognize, what should be rolled back ? Are there some
rules ?
It is possible, that some DBs issue the commit and other the rollback,
so the result would be inconsistent ?
Best Regards,
Petr
--
//www.freelists.org/webpage/oracle-l
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1382 / Virus Database: 1511/3685 - Release Date: 06/06/11
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
