Implementing E-Transactions with Asynchronous Replication
IEEE Transactions on Parallel and Distributed Systems
e-Transactions: End-to-End Reliability for Three-Tier Architectures
IEEE Transactions on Software Engineering
Blocking Reduction in Two-phase Commit Protocol with Multiple Backup Sites
DNIS '00 Proceedings of the International Workshop on Databases in Networked Information Systems
Reducing the blocking in two-phase commit with backup sites
Information Processing Letters
Preventing orphan requests by integrating replication and transactions
ADBIS'07 Proceedings of the 11th East European conference on Advances in databases and information systems
The circular two-phase commit protocol
DASFAA'07 Proceedings of the 12th international conference on Database systems for advanced applications
Transaction manager failover: a case study using JBOSS application server
OTM'06 Proceedings of the 2006 international conference on On the Move to Meaningful Internet Systems: AWeSOMe, CAMS, COMINF, IS, KSinBIT, MIOS-CIAO, MONET - Volume Part II
Reducing Blocking Risks of Atomic Transactions in MANETs Using a Backup Coordinator
International Journal of Ambient Computing and Intelligence
Hi-index | 0.00 |
In distributed data base systems (DDBSs), a transaction blocks during two-phase commit (2PC) processing if the coordinator site fails and at the same time some participant site has declared itself ready to commit the transaction. The blocking phenomena reduces availability of the system since the blocked transactions keep all the resources until they receive the final command from the coordinator after its recovery. To remove the blocking problem in 2PC protocol, three phase commit (3PC) protocol was proposed.Although 3PC protocol eliminates the blocking problem, it involves an extra round of message transmission, which further degrades the performance of DDBSs. In this paper, we propose a backup commit (BC) protocol by including backup phase to 2PC protocol. In this, one backup site is attached to each coordinator site. After receiving responses from all participants in the first phase, the coordinator communicates its decision only to its backup site in the backup phase. Afterwards, it sends final decision to participants. When blocking occurs due to the failure of the coordinator site, the participant sites consult coordinator's backup site and follow termination protocols. In this way, BC protocol achieves non-blocking property in most of the coordinator site failures. However, in the worst case, the blocking can occur in BC protocol when both the coordinator and its backup site fail simultaneously. If such a rare case occurs, the participants wait until the recovery of either the coordinator site or the backup site. BC protocol suits best for DDBS environments in which sites fail frequently and messages take longer delivery time. Through simulation experiments it has been shown that BC protocol exhibits superior throughput and response time performance over 3PC protocol and performs closely with 2PC protocol.