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

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

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

OOPSLA 2001Jim Tyhurst, Ph.D. Concurrent Updates Multiple users are updating data. Multiple users are updating data. More than one user may try to update a specific record at the same time. More than one user may try to update a specific record at the same time. For example, updating customer data from multiple channels: 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

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

OOPSLA 2001Jim Tyhurst, Ph.D. Concurrent Updates: Example Customer information includes 'Region' and 'Account Manager'. Customer information includes 'Region' and 'Account Manager'. Customer Service Representative updates customer record with new Region and default Account Manager when notified of address change. Customer Service Representative updates customer record with new Region and default Account Manager when notified of address change. Sales Manager updates customer record when account manager changes. Sales Manager updates customer record when account manager changes.

OOPSLA 2001Jim Tyhurst, Ph.D. Concurrent Updates: Example Customer Service Representative knows that Bob has moved from Tampa to Boston. Customer Service Representative knows that Bob has moved from Tampa to Boston. Sales Manager knows that the South East region has been split, so Tampa customers have a new account manager. Sales Manager knows that the South East region has been split, so Tampa customers have a new account manager.

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

OOPSLA 2001Jim Tyhurst, Ph.D. Scenario: Independent Updates

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

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

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

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

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

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

OOPSLA 2001Jim Tyhurst, Ph.D. Transaction Forces Failure to commit. 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. Probability of a commit failure. Consequences of a commit failure. Consequences of a commit failure.

OOPSLA 2001Jim Tyhurst, Ph.D. Transaction Forces Length of Tx 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.

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

OOPSLA 2001Jim Tyhurst, Ph.D. Transaction Models Flat Transaction Flat Transaction Nested Transaction Nested Transaction Distributed Transaction Distributed Transaction Conversational Transaction Conversational Transaction Queued Transaction Queued Transaction

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

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

OOPSLA 2001Jim Tyhurst, Ph.D. Distributed Transaction Two-phase commit process, so that single Tx can span multiple systems. 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. 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. Useful when the domain model is distributed across servers.

OOPSLA 2001Jim Tyhurst, Ph.D. Conversational Transaction One business Tx is implemented with a series of data Tx's: 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". Naive implementation leads to "Last Commit Wins".

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

OOPSLA 2001Jim Tyhurst, Ph.D. Transaction Models Flat Transaction Flat Transaction Nested Transaction Nested Transaction Distributed Transaction Distributed Transaction Conversational Transaction Conversational Transaction Queued Transaction Queued Transaction

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

OOPSLA 2001Jim Tyhurst, Ph.D. Transaction Failures Goal: Want to avoid causing the user to perform rework to resubmit a transaction. 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? Problem: How can a transaction be replayed automatically, rather than simply reporting a failure to the user?

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

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

OOPSLA 2001Jim Tyhurst, Ph.D. Check Out an Object Maintain a "lock" for a long period of time across transactions. 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. 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. Application checks out a copy, makes changes, checks in the changed copy.

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

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

OOPSLA 2001Jim Tyhurst, Ph.D. Transaction Specification Save the sequence of messages that can be sent to cause the desired changes to occur. Save the sequence of messages that can be sent to cause the desired changes to occur. Aspect Change Specification Array of messages Aspect Change Specification Array of messages Array of SQL Commands [c1, c2,..., cN] Array of SQL Commands [c1, c2,..., cN]

OOPSLA 2001Jim Tyhurst, Ph.D. Dirty Object Pool Keep a copy of the object in its changed state, where the copy is outside of the database view. 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. When the database view is refreshed, use the copy to reapply the changes. View of Database Dirty Object Pool

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

OOPSLA 2001Jim Tyhurst, Ph.D. Resolving Conflicts First Commit Wins First Commit Wins Last Commit Wins Last Commit Wins Merge Conflicting Updates Merge Conflicting Updates Business Tx 1 Business Tx 2 t0t1t2

OOPSLA 2001Jim Tyhurst, Ph.D. Resolving Conflicts Pattern Primary Concern First Commit Wins Do not overwrite previous changes. Last Commit Wins Avoid reentry of data and risk of overwrite is small (and acceptable). Merge Conflicting Updates Avoid overwriting with minimal rework.

OOPSLA 2001Jim Tyhurst, Ph.D. First Commit Wins Primary concern: First set of changes forces second user to start again with revised data. 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. 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. Some application servers provide notification for early detection of conflicting changes.

OOPSLA 2001Jim Tyhurst, Ph.D. Last Commit Wins Primary concern: Avoid rework by user. Primary concern: Avoid rework by user. Assumes risk of conflict is small and consequences of overwriting data are acceptable. 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. Replay user's changes in a new transaction, overwriting previously committed changes if necessary.

OOPSLA 2001Jim Tyhurst, Ph.D. Merge Conflicting Updates Primary Concern: Avoid overwriting previous changes with minimal rework by user. Primary Concern: Avoid overwriting previous changes with minimal rework by user. Option 1: Let user confirm merges. 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. Option 2: Perform merge automatically with some type of resolution algorithm.

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

OOPSLA 2001Jim Tyhurst, Ph.D. Conclusion Three-Tier Architecture often uses Conversational Transaction. Three-Tier Architecture often uses Conversational Transaction. Naive implementation leads to Last Commit Wins, whereas Client/Server typically provides First Commit Wins. 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. Additional development effort is required to detect and resolve conflicts in overlapping business transactions.