Choosing Transaction Models for Enterprise Applications

1. Choosing Transaction Models for Enterprise Applications Jim Tyhurst, Ph.D. Tyhurst Technology Group LLC OOPSLA 2001

2. Overview • Usage scenarios. • Architecture characteristics. • Forces that influence design decisions. • Transaction models. • Infrastructure to handle failures. • Resolving conflicts. Jim Tyhurst, Ph.D.

3. Scenario: Concurrent Updates CSR Sales Manager Jim Tyhurst, Ph.D.

4. Concurrent Updates • Multiple users are updating data. • More than one user may try to update a specific record at the same time. • For example, updating customer data from multiple channels: • Call Center (live Customer Service Rep) • Automated Call Center (Interactive Voice) • Web forms • Applications within the company Jim Tyhurst, Ph.D.

5. Use Case: Customer Service Rep changes address. Use Case: Sales Manager changes assignment of Account Managers. Customer Record: Name: Bob Region: South East Acct Mgr: Yolanda Concurrent Updates: Example Jim Tyhurst, Ph.D.

6. Concurrent Updates: Example Original Data Name: Bob Region: South East Acct Mgr: Yolanda Update 1 Update 2 Name: Bob Region: North East Acct Mgr: Andy Name: Bob Region: South East Acct Mgr: Zoe Jim Tyhurst, Ph.D.

7. Scenario:Independent Updates Jim Tyhurst, Ph.D.

8. Independent Updates • Multiple users are adding new data. • Each transaction is mutually exclusive of the others. • For example, logging events: • Factory data • Customer calls • Environmental observations Jim Tyhurst, Ph.D.

9. Overview • Usage scenarios. • Architecture characteristics. • Forces that influence design decisions. • Transaction models. • Infrastructure to handle failures. • Resolving conflicts. Jim Tyhurst, Ph.D.

10. Fat client. View and model on same layer. Continuous connection to DBMS. Long transactions (pessimistic locking). Client/Server Characteristics Jim Tyhurst, Ph.D.

11. Fat client. View and model on same layer. Continuous connection to DBMS. Long transactions (pessimistic locking). Thin client. Model on middle tier. Intermittent connection to DBMS. User works outside of a transaction. Client/Server vs. Three-Tier Jim Tyhurst, Ph.D.

12. Overview • Usage scenarios. • Architecture characteristics. • Forces that influence design decisions. • Transaction models. • Infrastructure to handle failures. • Resolving conflicts. Jim Tyhurst, Ph.D.

13. Transaction Forces • Designer must map business Tx's to server Tx's. • Shared objects must be modified in a Tx. • View of shared objects should be updated at Tx boundaries. Jim Tyhurst, Ph.D.

14. Transaction Forces • Failure to commit. • Caused by conflict with another Tx. • Must abort and start a new Tx. • Alternatives: • Retry automatically. • Force user to do rework. • Probability of a commit failure. • Consequences of a commit failure. Jim Tyhurst, Ph.D.

15. Transaction Forces • Length of Tx • Pessimistic locking ties up resources. • With no locks, risk of commit failure increases with the length of the Tx. • Large number of open Tx's usually degrades performance significantly. Jim Tyhurst, Ph.D.

16. Overview • Usage scenarios. • Architecture characteristics. • Forces that influence design decisions. • Transaction models. • Infrastructure to handle failures. • Resolving conflicts. Jim Tyhurst, Ph.D.

17. Transaction Models • Flat Transaction • Nested Transaction • Distributed Transaction • Conversational Transaction • Queued Transaction Jim Tyhurst, Ph.D.

18. Flat Transaction • All changes occur in a single Tx with no internal structure. • Easy to implement. • Supported by all database systems. Jim Tyhurst, Ph.D.

19. Nested Transaction • Changes are organized in hierarchical increments. • Each embedded Tx can be rolled back without affecting higher level Tx's or sibling Tx's. • Not supported by many systems. Jim Tyhurst, Ph.D.

20. Distributed Transaction • Two-phase commit process, so that single Tx can span multiple systems. • Each server verifies that it can commit its portion of the Tx before any server actually performs its portion of the commit. • Useful when the domain model is distributed across servers. Jim Tyhurst, Ph.D.

21. Conversational Transaction • One business Tx is implemented with a series of data Tx's: • Read data in one Tx. • Modify data outside of Tx. • Submit changes in a second Tx. • Naive implementation leads to "Last Commit Wins". Jim Tyhurst, Ph.D.

22. Queued Transaction • Submit a Tx Specification to a queue. • Client does not wait for Tx. • Option 1: Single queue reader executes Tx's sequentially as they are read from the queue. • Option 2: Multiple readers execute Tx's. • Works well for independent Tx's. • More difficult to handle failures. Jim Tyhurst, Ph.D.

23. Transaction Models • Flat Transaction • Nested Transaction • Distributed Transaction • Conversational Transaction • Queued Transaction Jim Tyhurst, Ph.D.

24. Overview • Usage scenarios. • Architecture characteristics. • Forces that influence design decisions. • Transaction models. • Infrastructure to handle failures. • Resolving conflicts. Jim Tyhurst, Ph.D.

25. Transaction Failures • Goal:Want to avoid causing the user to perform rework to resubmit a transaction. • Problem:How can a transaction be replayed automatically, rather than simply reporting a failure to the user? Jim Tyhurst, Ph.D.

26. Avoid Reporting Failure • Avoid failure • Lock an Object • Check Out an Object • Recover from failure • Replay Changes • Transaction Specification • Aspect Change Specification • Dirty Object Pool Jim Tyhurst, Ph.D.

27. Lock an Object • Reduce the risk of commit failure. • Obtain a write lock on an object before modifying it. • Assures that the locking process is the only one to update an object. • Be careful to avoid deadlock when acquiring multiple locks. Jim Tyhurst, Ph.D.

28. Check Out an Object • Maintain a "lock" for a long period of time across transactions. • Develop a lock table to hold persistent locks for objects that have been checked out. • Application checks out a copy, makes changes, checks in the changed copy. Jim Tyhurst, Ph.D.

29. Replay Changes (Specification of) Changes • Keep the changes independent from the view of the repository. • When the view is refreshed, the changes may be replayed. Apply changes View of Database Jim Tyhurst, Ph.D.

30. Preserving Changes • Problem:How can changes to domain model objects be saved independently from the domain model? • Transaction Specification • Dirty Object Pool Jim Tyhurst, Ph.D.

31. Transaction Specification • Save the sequence of messages that can be sent to cause the desired changes to occur. • Aspect Change SpecificationArray of messages<receiver, method signature, args> • Array of SQL Commands[c1, c2, ..., cN] Jim Tyhurst, Ph.D.

32. Dirty Object Pool • Keep a copy of the object in its changed state, where the copy is outside of the database view. • When the database view is refreshed, use the copy to reapply the changes. Dirty Object Pool View of Database Jim Tyhurst, Ph.D.

33. Overview • Usage scenarios. • Architecture characteristics. • Forces that influence design decisions. • Transaction models. • Infrastructure to handle failures. • Resolving conflicts. Jim Tyhurst, Ph.D.

34. Resolving Conflicts Business Tx 1 • First Commit Wins • Last Commit Wins • Merge Conflicting Updates Business Tx 2 t0 t1 t2 Jim Tyhurst, Ph.D.

35. Resolving Conflicts Jim Tyhurst, Ph.D.

36. First Commit Wins • Primary concern: First set of changes forces second user to start again with revised data. • Easy to detect failure when second user commits, but this maximizes the amount of rework. • Some application servers provide notification for early detection of conflicting changes. Jim Tyhurst, Ph.D.

37. Last Commit Wins • Primary concern: Avoid rework by user. • Assumes risk of conflict is small and consequences of overwriting data are acceptable. • Replay user's changes in a new transaction, overwriting previously committed changes if necessary. Jim Tyhurst, Ph.D.

38. Merge Conflicting Updates • Primary Concern: Avoid overwriting previous changes with minimal rework by user. • Option 1: Let user confirm merges. • May be difficult to develop additional user interface. • Option 2: Perform merge automatically with some type of resolution algorithm. Jim Tyhurst, Ph.D.

39. Overview • Usage scenarios. • Architecture characteristics. • Forces that influence design decisions. • Transaction models. • Infrastructure to handle failures. • Resolving conflicts. Jim Tyhurst, Ph.D.

40. Conclusion • Three-Tier Architecture often uses Conversational Transaction. • Naive implementation leads to Last Commit Wins, whereas Client/Server typically provides First Commit Wins. • Additional development effort is required to detect and resolve conflicts in overlapping business transactions. Jim Tyhurst, Ph.D.