Re: Heuristic rollback /commit

From: <>
Date: Wed, 8 Jun 2011 13:20:21 +0300
Message-ID: <>

Wandering if this case can be covered by CAP (Brewer's) 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" <>                                                                                       
  To:         "'oracle-l'" <>                                                                                                
  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

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).


Jonathan Lewis

  • Original Message ----- From: "Petr Novak" <> To: "'oracle-l'" <> Sent: Tuesday, June 07, 2011 3:35 PM Subject: Heuristic rollback /commit


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,


No virus found in this message.
Checked by AVG -
Version: 10.0.1382 / Virus Database: 1511/3685 - Release Date: 06/06/11


-- Received on Wed Jun 08 2011 - 05:20:21 CDT

Original text of this message