e-Transactions: End-to-End Reliability for Three-Tier Architectures

1. e-Transactions: End-to-End Reliability for Three-Tier Architectures Svend Frølund and Rachid Guerraoui

2. Applicable to three-tier architectures • Front-end clients • Middle-tier application servers • Back-end database servers

3. Three-tier Architecture

4. Typical three-tier architectures fail to provide reliability guarantees • At-most-once processing: request is executed once or not at all • Server failure results in error • No knowledge if transaction was successful • Resubmitting request may result in duplicate transaction

5. Exactly-once transaction abstraction • Mask failures in the middle and back-end tiers • Eliminate resubmission • What if client crashes?

6. e-Transactions • Guarantees exactly-once transaction, unless the client crashes • If the client crashes, at-most-once processing can be assumed • Up to user to figure out what has happened • Crashed client does not affect other clients

7. Need for e-Transactions:Improvements over existing reliability concepts for three-tier architectures • Addresses all three tiers • Includes liveness properties of replicated services • Also includes safety properties of transaction-processing systems

8. e-Transactions Algorithm • Distributed commit scheme • Primary-backup replication scheme • Interfaces with COTS technologies, particularly database servers • Client does not need access to local storage • Assumes perfect knowledge about failures

9. e-Transactions Model: System • Distributed System • Finite processes communicate by message passing • A process is either up or down • Crash – transition from up to down • Recovery – transition from down to up • Crash has no impact on stable storage • Processes do not behave maliciously • Communications are reliable

10. e-Transactions Model: Clients • Set of processes (ci Client) • Domain of request values and domain of result values • (nil  Request  Result) • Operation issue() : Request  Result

11. e-Transactions Model: Application Servers • Set of processes (ai AppServer) • Application servers are stateless • Function compute() : Request  Result • Compute function is non-blocking

12. e-Transactions Model: Database Servers • Set of processes (si Server) • Function vote() : Result  Vote where Vote = {yes, no} • Function decide() : Result  Outcome  Out-come where Outcome = {commit, abort}

13. e-Transactions Specification • Termination – liveness guarantee by preventing blocking situations • Agreement – safety guarantee by ensuring consistency of client and databases • Validity – restrict the space of possible results (exclude meaningless results)

14. e-Transactions Specification: Termination • (T.1) If the client issues a request, then, unless it crashes, the client eventually delivers a result • (T.2) If any database server votes for a result, then the database server eventually commits or aborts the result

15. e-Transactions Specification: Agreement • (A.1) No result is delivered by the client unless the result is committed by all database servers • (A.2) No database server commits more than one result for the same request • (A.3) No two database servers decide differently on the same result

16. e-Transactions Specification: Validity • (V.1) If the client issues a request and delivers a result, then the result has been computed by an application server with the request as a parameter • (V.2) No database server commits a result unless all database servers have voted yes for that result

17. e-Transactions Implementation: Assumptions • Closed system, the only entities are the client, the application servers, and the database servers • Communication channels are reliable • Knowledge of failures is perfect

18. e-Transactions Implementation:Client Algorithm

19. e-Transactions Implementation:Database Server Algorithm

20. e-Transactions Implementation: Primary Application Server Algorithm

21. e-Transactions Implementation: Backup Application Server Algorithm

22. e-Transactions Protocol Correctness: Lemma1 No primary application server remains blocked forever in one of the wait statements of lines 8, 10, 14, and 17, in the primary application server algorithm

23. e-Transactions Protocol Correctness: Lemma2 Let t be any time. 1) At most one application server is the primary application server at t and 2) there is a time t’ ≥ t after which some application server remains primary forever

24. e-Transactions Protocol Correctness: Lemma3 (Termination T.1) If the client issues a request, then unless it crashes, the client eventually delivers a result

25. e-Transactions Protocol Correctness: Lemma4 (Termination T.2) If any database server votes for a result, then the database server eventually commits or aborts the result

26. e-Transactions Protocol Correctness: Lemma5 (Agreement A.1) No result is delivered by the client, unless the result is committed by all database servers

27. e-Transactions Protocol Correctness: Lemma6 (Agreement A.2) No database server commits more than one result for the same request

28. e-Transactions Protocol Correctness: Lemma7 (Agreement A.3) No two database servers decide differently for the same result

29. e-Transactions Protocol Correctness: Lemma8 (Validity V.1) If the client issues a request and delivers a result, then the result has been computed by an application server with the request as a parameter

30. e-Transactions Protocol Correctness: Lemma8 (Validity V.2) No database server commits a result unless all database servers have voted yes for that result

31. e-Transactions Performance • Latency – 16% increase over baseline unreliable algorithm, compared to 23% increase over baseline for a 2PC algorithm that guarantees at-most-once semantics • Scalability – linear increase in response time with respect to the number of database servers

32. e-Transactions Related Work: Transaction Monitors • Middle-tier server encapsulates processing as an atomic transaction • Assumes stable storage at the client • Nothing prevents transaction coordinator from crashing and blocking all participants

33. e-Transactions Related Work: Persistent Queues • Client submits request through a persistent client-queue • Server processes request and stores result into a persistent server-queue • Client and server queues must be replicated with additional cost • Atomic commitment mechanism to avoid blocking

34. e-Transactions Related Work: Message Logging • Clients log incoming and outgoing requests • Server logs incoming requests and outgoing replies • Server stores database operations • Requires intertransaction state at the client

35. e-Transactions Related Work: Object Groups • Single transaction entity that is made highly available through a replication and coordination protocol • Overhead of coordinating replicated application servers • Replication of database servers makes use of COTS databases complicated

36. e-Transactions Current Status:Total-e-Transactions • HP distributed transaction management system • Java implementation based on Sun’s Java Transaction Service standard • Utilizes OMG’s Object Transaction Service for Interoperability

37. References • e-Transactions: end-to-end reliability for three-tier architecturesFrolund, S.; Guerraoui, R.; Software Engineering, IEEE Transactions on Volume 28,  Issue 4,  April 2002 Page(s):378 – 395 • Three Tier Software Architectures (http://www.sei.cmu.edu/str/descriptions/threetier.html) • Total-e-Transactions Frequently Asked Questions www.hpmiddleware.com/downloads/ pdf/Total-e-Transactions_2.2_FAQ.pdf