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

OOPSLA 2001

Choosing Transaction Models Choosing Transaction Models for Enterprise Applicationsfor Enterprise Applications

Jim Tyhurst, Ph.D.Jim Tyhurst, Ph.D.

Tyhurst Technology Group LLCTyhurst Technology Group LLC

OOPSLA 2001 Jim Tyhurst, Ph.D.

OverviewOverview

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.


Scenario: Concurrent UpdatesScenario: Concurrent Updates

Update 1

Update 2

CSR

Sales Manager


Concurrent UpdatesConcurrent Updates

Multiple users are updating data.Multiple users are updating data. More than one user may try to update a More than one user may try to update a

specific record at the same time.specific record at the same time. For example, updating customer data For example, updating customer data

from multiple channels:from multiple channels:– Call Center (live Customer Service Rep)Call Center (live Customer Service Rep)– Automated Call Center (Interactive Voice)Automated Call Center (Interactive Voice)– Web formsWeb forms– Applications within the companyApplications within the company


Concurrent Updates: ExampleConcurrent Updates: Example

Use Case: Use Case: Customer Service Customer Service Rep changes Rep changes address.address.

Use Case: Sales Use Case: Sales Manager changes Manager changes assignment of assignment of Account Managers.Account Managers.

Customer Record:Customer Record: Name: BobName: Bob Region: South EastRegion: South East Acct Mgr: YolandaAcct Mgr: Yolanda


Concurrent Updates: ExampleConcurrent Updates: Example

Name: BobRegion: South EastAcct Mgr: Yolanda

Name: BobRegion: North EastAcct Mgr: Andy

Name: BobRegion: South EastAcct Mgr: Zoe

Update 1 Update 2

Original Data


Scenario:Scenario:Independent UpdatesIndependent Updates

Event 1

Event 2


Independent UpdatesIndependent Updates

Multiple users are adding new data.Multiple users are adding new data. Each transaction is mutually exclusive Each transaction is mutually exclusive

of the others.of the others. For example, logging events:For example, logging events:

– Factory dataFactory data– Customer callsCustomer calls– Environmental observationsEnvironmental observations


OverviewOverview

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.


Client/Server CharacteristicsClient/Server Characteristics

Fat client.Fat client. View and model on View and model on

same layer.same layer. Continuous Continuous

connection to connection to DBMS.DBMS.

Long transactions Long transactions (pessimistic (pessimistic locking).locking).


Client/Server vs. Three-TierClient/Server vs. Three-Tier

Fat client.Fat client. View and model on View and model on

same layer.same layer. Continuous Continuous


Long transactions Long transactions (pessimistic (pessimistic locking).locking).

Thin client.Thin client. Model on middle Model on middle

tier.tier. Intermittent Intermittent


User works outside User works outside of a transaction.of a transaction.


OverviewOverview

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.


Transaction ForcesTransaction Forces

Designer must map business Tx's to Designer must map business Tx's to server Tx's.server Tx's.

Shared objects must be modified in a Shared objects must be modified in a Tx.Tx.

View of shared objects should be View of shared objects should be updated at Tx boundaries.updated at Tx boundaries.



Failure to commit.Failure to commit.– Caused by conflict with another Tx.Caused by conflict with another Tx.– Must abort and start a new Tx.Must abort and start a new Tx.– Alternatives:Alternatives:

» Retry automatically.Retry automatically.» Force user to do rework.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.



Length of TxLength of Tx– Pessimistic locking ties up resources.Pessimistic locking ties up resources.– With no locks, risk of commit failure With no locks, risk of commit failure

increases with the length of the Tx.increases with the length of the Tx.– Large number of open Tx's usually Large number of open Tx's usually

degrades performance significantly.degrades performance significantly.


OverviewOverview

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.


Transaction ModelsTransaction Models

Flat TransactionFlat Transaction Nested TransactionNested Transaction Distributed TransactionDistributed Transaction Conversational TransactionConversational Transaction Queued TransactionQueued Transaction


Flat TransactionFlat Transaction

All changes occur in a single Tx with no All changes occur in a single Tx with no internal structure.internal structure.

Easy to implement.Easy to implement. Supported by all database systems.Supported by all database systems.


Nested TransactionNested Transaction

Changes are organized in hierarchical Changes are organized in hierarchical increments.increments.

Each embedded Tx can be rolled back Each embedded Tx can be rolled back without affecting higher level Tx's or without affecting higher level Tx's or sibling Tx's.sibling Tx's.

Not supported by many systems.Not supported by many systems.


Distributed TransactionDistributed Transaction

Two-phase commit process, so that Two-phase commit process, so that single Tx can span multiple systems.single Tx can span multiple systems.

Each server verifies that it can commit Each server verifies that it can commit its portion of the Tx before any server its portion of the Tx before any server actually performs its portion of the actually performs its portion of the commit.commit.

Useful when the domain model is Useful when the domain model is distributed across servers.distributed across servers.


Conversational TransactionConversational Transaction

One business Tx is implemented with a One business Tx is implemented with a series of data Tx's:series of data Tx's:– Read data in one Tx.Read data in one Tx.– Modify data outside of Tx.Modify data outside of Tx.– Submit changes in a second Tx.Submit changes in a second Tx.

Naive implementation leads to "Last Naive implementation leads to "Last Commit Wins".Commit Wins".


Queued TransactionQueued 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 Option 1: Single queue reader executes Tx's

sequentially as they are read from the queue.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.


Transaction ModelsTransaction Models

Flat TransactionFlat Transaction Nested TransactionNested Transaction Distributed TransactionDistributed Transaction Conversational TransactionConversational Transaction Queued TransactionQueued Transaction


OverviewOverview

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.


Transaction FailuresTransaction Failures

Goal:Goal:Want to avoid causing the user to Want to avoid causing the user to perform rework to resubmit a perform rework to resubmit a transaction.transaction.

Problem:Problem:How can a transaction be replayed How can a transaction be replayed automatically, rather than simply automatically, rather than simply reporting a failure to the user?reporting a failure to the user?


Avoid Reporting FailureAvoid Reporting Failure

Avoid failureAvoid failure– Lock an ObjectLock an Object– Check Out an ObjectCheck Out an Object

Recover from failureRecover from failure– Replay ChangesReplay Changes– Transaction SpecificationTransaction Specification– Aspect Change SpecificationAspect Change Specification– Dirty Object PoolDirty Object Pool


Lock an ObjectLock an Object

Reduce the risk of commit failure.Reduce the risk of commit failure. Obtain a write lock on an object before Obtain a write lock on an object before

modifying it.modifying it. Assures that the locking process is the Assures that the locking process is the

only one to update an object.only one to update an object. Be careful to avoid deadlock when Be careful to avoid deadlock when

acquiring multiple locks.acquiring multiple locks.


Check Out an ObjectCheck Out an Object

Maintain a "lock" for a long period of Maintain a "lock" for a long period of time across transactions.time across transactions.

Develop a lock table to hold persistent Develop a lock table to hold persistent locks for objects that have been locks for objects that have been checked out.checked out.

Application checks out a copy, makes Application checks out a copy, makes changes, checks in the changed copy.changes, checks in the changed copy.


Replay ChangesReplay Changes

Keep the changes Keep the changes independent from independent from the view of the the view of the repository.repository.

When the view is When the view is refreshed, the refreshed, the changes may be changes may be replayed.replayed.

View of Database

(Specification of) Changes

Apply changes


Preserving ChangesPreserving Changes

Problem:Problem:How can changes to domain model How can changes to domain model objects be saved independently from objects be saved independently from the domain model?the domain model?– Transaction SpecificationTransaction Specification– Dirty Object PoolDirty Object Pool


Transaction SpecificationTransaction Specification

Save the sequence of messages that Save the sequence of messages that can be sent to cause the desired can be sent to cause the desired changes to occur.changes to occur.

Aspect Change SpecificationAspect Change SpecificationArray of messagesArray of messages<receiver, method signature, args><receiver, method signature, args>

Array of SQL CommandsArray of SQL Commands[c1, c2, ..., cN][c1, c2, ..., cN]


Dirty Object PoolDirty Object Pool

Keep a copy of the Keep a copy of the object in its changed object in its changed state, where the state, where the copy is outside of copy is outside of the database view.the database view.

When the database When the database view is refreshed, view is refreshed, use the copy to use the copy to reapply the reapply the changes.changes. View of Database

Dirty Object Pool


OverviewOverview

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.


Resolving ConflictsResolving Conflicts

First Commit WinsFirst Commit Wins Last Commit WinsLast Commit Wins Merge Conflicting UpdatesMerge Conflicting Updates

Business Tx 1

Business Tx 2

t0 t1 t2


Resolving ConflictsResolving Conflicts

PatternPattern Primary ConcernPrimary Concern

First Commit WinsFirst Commit Wins Do not overwrite Do not overwrite previous changes.previous changes.

Last Commit WinsLast Commit Wins Avoid reentry of data Avoid reentry of data and risk of overwrite is and risk of overwrite is small (and acceptable).small (and acceptable).

Merge Conflicting Merge Conflicting UpdatesUpdates

Avoid overwriting with Avoid overwriting with minimal rework.minimal rework.


First Commit WinsFirst Commit Wins

Primary concern: First set of changes Primary concern: First set of changes forces second user to start again with forces second user to start again with revised data.revised data.

Easy to detect failure when second user Easy to detect failure when second user commits, but this maximizes the amount commits, but this maximizes the amount of rework.of rework.

Some application servers provide Some application servers provide notification for early detection of notification for early detection of conflicting changes.conflicting changes.


Last Commit WinsLast Commit Wins

Primary concern: Avoid rework by user.Primary concern: Avoid rework by user. Assumes risk of conflict is small and Assumes risk of conflict is small and

consequences of overwriting data are consequences of overwriting data are acceptable.acceptable.

Replay user's changes in a new Replay user's changes in a new transaction, overwriting previously transaction, overwriting previously committed changes if necessary.committed changes if necessary.


Merge Conflicting UpdatesMerge Conflicting Updates

Primary Concern: Avoid overwriting Primary Concern: Avoid overwriting previous changes with minimal rework previous changes with minimal rework by user.by user.

Option 1: Let user confirm merges.Option 1: Let user confirm merges.– May be difficult to develop additional user May be difficult to develop additional user

interface.interface. Option 2: Perform merge automatically Option 2: Perform merge automatically

with some type of resolution algorithm.with some type of resolution algorithm.


OverviewOverview

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.


ConclusionConclusion

Three-Tier Architecture often uses Three-Tier Architecture often uses Conversational Transaction.Conversational Transaction.

Naive implementation leads to Last Naive implementation leads to Last Commit Wins, whereas Client/Server Commit Wins, whereas Client/Server typically provides First Commit Wins.typically provides First Commit Wins.

Additional development effort is Additional development effort is required to detect and resolve conflicts required to detect and resolve conflicts in overlapping business transactions.in overlapping business transactions.

Documents

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