Win a copy of Java Concurrency Live Lessons this week in the Threads forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

two phase committ  RSS feed

 
Aishwarya Choudhari
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi all,
can anybody explain what is meant by two phase committ??
thanks,
aishwarya
 
Vivek Viswanathan
Ranch Hand
Posts: 350
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

The Container provides the ACID features to the Enterprise Component.
Durability guarantees that all the updates comitted to the storage area are made permanent, Durability is easily achived when there is a single Resource manager ( e.g Database ) but if there are multiple Resource manager and one of the resource managers undergoes a failure then then entire transaction has to be rollbacked on both the resouce managers.
Since this transaction requires more than one resource manager, the processing of committing the change to all the Repurce Managers takes place in Two Phases
Phase One :
It sends the begin commit singal to all the Resources Manages involded in the transactiom. At this stage any resource that wants to abort the transcation can reply rit now. If any resource decides to abort the transaction , then the entire transaction is aborted and no updates are carried out. Otherwise the transaction proceeds unless a Faliure occurs. To preven a failure all the changes are written to logs , that survive failures,and this log can be read after the crash so as to repeat the update after the crash.
Phase Two :
It starts only if Phase one completes , without an abort signal. Here all the Resource Managers perform the actual update.

This seperation of Transaction Completion into 2 phases is called the 2 Phase Commit Protocol.
Vivek
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That brings one thing up I've been intending to find out for a while now. From the textbook description of two-phased commit, you would think that between the two phases there is a period of time during which it is not possible to recover from certain types of failure, unless recovery is managed by the distributed transaction manager.
Let's say you have two resources A and B participating in a distributed transaction. In the first phase of the commit, both A and B give the go-ahead. The transaction manager then tells A and B to enter the second phase, but at this point it turns out that B has just crashed. My problem is that by that time A has already started the second phase and its commit is irrevocable.
The only consistent thing to do at this time is for B to commit the phase-1 transaction after crash recovery. That would not be a problem. But B cannot blindly do so, or you would have a possible inconsistency in case one of the resources vetoed the commit in phase 1. This would imply that distributed transactions imply distributed crash recovery. The transaction manager would have to keep its own persistent transaction logs and co-ordinate the the roll-back/roll-forward decisions on incomplete commits. That seems pretty hard to implement.
This line of reasoning has taken me far enough beyond the limits of my knowledge that I must have missed things. Does anyone know how distributed transactions really guarantee data integrity?
- Peter

[This message has been edited by Peter den Haan (edited May 08, 2001).]
 
David Egolf
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Indeed, it is somewhat hard to implement. We are adding recovery to JOTM, the ObjectWeb transaction manager, right now.

We broke the project into two major pieces. First, we implemented Howl, also an ObjectWeb project. Howl is is a high performance logger which provides the persistent storage necessary for the transaction manager. It is high performance because we want to allow > 10,000 transactions/second. (We realize that this is an optimistic goal for most platforms, but we didn't want to become the bottleneck.) You can learn more about Howl by attending Michael Giroux's presentation at ApacheCon 2004 next month in Las Vegas.

Second, we are adding recovey features to JOTM. We have to write logging records to the Howl journal every time we expect to commit a transaction. This includes the XA Xid of the transaction and the XA Xid which has been sent to every involved resource manager. The identity of the resource managers is also persisted. After a crash, we have to poll all potentially involved resource managers with the XA 'recover' message. Each resource manager responds with a list of their own indoubt transactions identified by XA Xid.

This part of the recovery is a known commodity. Our group has actually implemented it on other platforms for other 2-phase commit protocols. The hard part is acquiring connections to the remote resource managers. We are in an area outside the normal protocol specifications and some of the players are not XA compliant.

JOTM is used in the JOnAS J2EE platform and should be integrated into Geronimo later this year.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!