High Availability and Data Consistency for Three-Tier Enterprise Applications

High Availability and Data Consistency for Three-Tier Enterprise Applications

Wenbing Zhao (Cleveland State University, USA), Louise E. Moser (University of California, Santa Barbara, USA) and P. Michael Melliar-Smith (University of California, Santa Barbara, USA)
Copyright: © 2006 |Pages: 7
DOI: 10.4018/978-1-59140-799-7.ch089
OnDemand PDF Download:
No Current Special Offers


Enterprise applications, such as those for e-commerce and e-government, are becoming more and more critical to our economy and society. Such applications need to provide continuous service, 24 hours a day, 7 days a week. Any disruption in service, including both planned and unplanned downtime, can result in negative financial and social effects. Consequently, high availability and data consistency are critically important for enterprise applications. Enterprise applications are typically implemented as three-tier applications. A three-tier application consists of clients in the front tier, servers that perform the business logic processing in the middle tier, and database systems that store the application data in the backend tier, as shown in Figure 1. Within the middle tier, a server application typically uses a transaction processing programming model. When a server application receives a client’s request, it initiates one or more transactions, which often are distributed transactions. When it finishes processing the request, the server application commits the transaction, stores the resulting state in the backend database, and returns the result to the client. A fault in the middle tier might cause the abort of a transaction and/or prevent the client from knowing the outcome of the transaction. A fault in the backend tier has similar consequences. In some cases, the problems can be a lot worse. For example, a software design fault, or an inappropriate heuristic decision, might introduce inconsistency in the data stored in the database, which can take a long time to fix. Two alternative recovery strategies, namely roll-backward and roll-forward, can be employed to tolerate and recover from a fault. In roll-backward recovery, the state of the application that has been modified by a set of unfinished operations is reversed by restoring it to a previous consistent state. This strategy is used in transaction processing systems. In roll-forward recovery, critical components, processes, or objects are replicated on multiple computers so that if one of the replicas fails, the other replicas continue to provide service, which enables the system to advance despite the fault. Many applications that require continuous availability take the roll-forward approach. Replication is commonly employed in the backend tier to increase the reliability of the database system. There has been intense research (Frolund & Guerraoui, 2002; Zhao, Moser, & Melliar-Smith, 2005a) on the seamless integration of the roll-backward and roll-forward strategies in software infrastructures for three-tier enterprise applications, to achieve high availability and data consistency. High availability is a measure of the uptime of a system, and typically means five nines (99.999%) or better, which corresponds to 5.25 minutes of planned and unplanned downtime per year. Data consistency means that the application state stored in the database remains consistent after a transaction commits. Both transactions and replication require consistency, as the applications execute operations that change their states. Transactions require data consistency, and replication requires replica consistency.

Complete Chapter List

Search this Book: