1. Service-Oriented Computing: Semantics, Processes, Agents
August 2004
Chapter 11: Transaction Concepts
Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005
© Singh & Huhns

2. Highlights of this Chapter
Service-Oriented Computing: Semantics, Processes, Agents
August 2004
Highlights of this Chapter
Basic concepts
ACID properties
Schedules
Locking
Transactions over composed services
Relaxing serializability
Extended transaction models
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
© Singh & Huhns

3. Motivation
As services are employed for serious purposes, they will inevitably update information resources
Can we be sure that such updates preserve integrity?
What about when multiple services need to work together?
What about when the services are involved in a long-lived activity?
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

4. Transactions: 1
A transaction is a computation (i.e., program in execution) that accesses and possibly modifies a database:
Not the source code; not the binaries
Can be interleaved with other transactions
But guarantees certain correctness properties
The purpose of the transaction concept is to avoid the problems (“race conditions”) that may arise from interleaving
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

5. Transactions: 2 Operation: action on a data item
Transaction: set of operations performed in a partial order according to the specifying program
Assume total order here for simplicity
A transaction makes a set of operations appear as one logical operation
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

6. ACID Properties
Properties that capture the consequences of a transaction being treated as one operation
(Failure) Atomicity—all or none—if failed then no changes to DB or messages
This is the vernacular notion of “transaction”
Consistency—don't violate DB integrity constraints: execution of the op is correct
Isolation (Atomicity)—partial results are hidden
Durability—effects (of transactions that "happened" or committed) are forever
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

7. Programmer-DBMS Contract
If each transaction is individually correct [programmer], then all transactions are jointly correct [DBMS]
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

8. Transaction Lifecycle
A transaction goes through well-defined stages in its life (always terminating)
Inactive
Active (may read and write)
Entire business logic takes place here
Precommit (no errors during execution; needed for mutual commitment protocols)
Failed (errors)
Committed (the DBMS decides this)
Forgotten (the DBMS reclaims data structures)
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

9. Schedules
Schedules are histories of computations showing all events of interest
Schedule of T1...Tn has all ops of T1...Tn in the same order as within each Ti, but interleaved across Ti to model concurrency
Includes active transactions
Typically a partial order among events
Two challenges
What are the bad schedules?
How can the DBMS prevent them?
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

10. Conflict Order-sensitivity of operations
Two operations of different transactions, but on the same data item, conflict if
Their mutual order is significant, i.e., determines at least one of the following:
The final value of that item read by future transactions
The value of the item as read by present transactions
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

11. Serial Schedules
Transactions are wholly before or after others (i.e., occur one by one)
Clearly, we must allow for service requests to come in slowly, one-by-one
Thus, under independence of transactions (assuming each transaction is correct), serial schedules are obviously correct
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

12. Serializable Schedules
Interleaved schedules are desirable
Why?
Those equivalent to some serial schedule. Here equivalent can mean
Conflict equivalent—all pairs of conflicting ops are ordered the same way
View equivalent—all users get the same view
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

13. Achieving Serializability
Optimistically: Let each transaction run, but check for serializability before committing
Pessimistically: Use a protocol, e.g., locking, to ensure that only serializable schedules are realized
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

14. Locks Lock item x while using item x
Binary: at most one party may lock x
Lock(x): acquire the lock
Computation hangs until lock(x) returns, i.e., the lock is acquired
Unlock(x): relinquish the lock
Gives mutual exclusion but restrictive
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

15. Multimode Locks
When one party has an exclusive lock, no other party may have an exclusive or a shared lock
Shared-lock(x) needed for read(x)
Others can also hold a shared lock
Exclusive-lock(x) needed for write(x)
No one else can concurrently hold a shared or exclusive lock
Can be upgraded (read to write) or downgraded (write to read)
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

16. Achtung! By itself, using locks does not guarantee serializability
What is an example of a bad schedule obtained while using locks?
A locking protocol, i.e., how locks are acquired and released, is critical
That is, locks on different data items must be related
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

17. Two-Phase Locking (2PL)
Two phases in a transaction’s life
Growing phase: acquire but not release locks
Shrinking phase: release but not acquire locks
Guarantees serializability, but can deadlock
Strict 2PL releases all locks at once when the transaction commits or rolls back
Ensures rigorous schedules (to be discussed)
But can deadlock
Conservative 2PL: takes all locks early; risks starvation
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

18. Reading From
T1 reads from T2 if the schedule contains a subsequence w2(x)...r1(x), where
w2 is the first write on x going backwards from r1(x)
a2 doesn’t occur between w2 and r1
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

19. Recoverable Schedules
In which a transaction commits after all transactions it read from have committed
In terms of the ACID properties, what is the risk in allowing a nonrecoverable schedule?
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

20. Avoid Cascading Aborts (ACA)
In which a transaction does not read from uncommitted transactions
What is the risk in allowing such reads?
Are cascading aborts
Legal?
Expensive?
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

21. Strict Schedules
In which an item can't be read or written until the previous transaction to write that item has committed (the aborted ones having been factored out)
Compare with ACA
This allows us to UNDO by restoring the before image
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

22. Rigorous Schedules
In which an item can't be read or written until the previous transaction to read or write that item has committed
Compare with strict schedules
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

23. Distributing ACID Transactions
Service-Oriented Computing: Semantics, Processes, Agents
August 2004
Distributing ACID Transactions
ACID transactions are applicable for
Brief, simple activities (few updates; seconds, at most)
On centralized architectures
Without distribution, ACID transactions would be a nonstarter outside of a single DBMS
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
© Singh & Huhns

24. Closed-Nested Distributed Transactions
Service-Oriented Computing: Semantics, Processes, Agents
August 2004
Closed-Nested Distributed Transactions
ACID transactions can be implemented in distributed settings
Consider two or more subtransactions, conceptually organized as a tree
Ensure atomicity through two-phase commit (2PC)
Ensure isolation so that results are not exposed till the global transaction commits
As in WS-AtomicTransaction
Why would ACID transactions ever be useful for SOC?
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
© Singh & Huhns

25. Transactions over Composed Services
Service-Oriented Computing: Semantics, Processes, Agents
August 2004
Transactions over Composed Services
Expedia
Composed service as a transaction
Composed Transaction Manager
Direct
users
service
service
United
Sheraton
LDB1
LDB2
Assume each service ensures serializability locally
Two main kinds of service agreements are possible:
Execution, e.g., LDB retains full control on execution even if in conflict with CTM
Communication, e.g., LDB decides what (control) information to release
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
© Singh & Huhns

26. Compositional Serializability
Service-Oriented Computing: Semantics, Processes, Agents
August 2004
Compositional Serializability
Transactions throughout the system should be serializable
CTM ensures that the composed transactions are serializable
This doesn't guarantee compositional serializability, because of indirect conflicts:
CTM does T1: r1(a); r1(c)
CTM does T2: r2(b); r2(d)
LDB1 does T3: w3(a); w3(b)
LDB2 does T4: w4(c); w4(d)
Since T1 and T2 are read-only, they are serializable.
LDB1 sees S1=r1(a); c1; w3(a); w3(b); c3; r2(b); c2
LDB2 sees S2=w4(c); r1(c); c1; r2(d); c2; w4(d); c4
Each LDB has a serializable schedule; yet jointly they put T1 before and after T2
Notice we would have lots of potential compositions, so the problem is worse
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
© Singh & Huhns

27. Service-Oriented Computing: Semantics, Processes, Agents
August 2004
Strawman 1: Tickets
Compositional serializability fails because of local conflicts that the CTM does not see
Fix by always causing conflicts--whenever two composed transactions execute at a site, they must conflict there. Indirect conflicts become local conflicts visible to the LDB
Make each composed transaction increment a ticket at each site
Downside:
Causes all local subtransactions of a transaction to go through a local hotspot
Composed transactions are serialized, but only because many are aborted!
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
© Singh & Huhns

28. Strawman 2: Rigorous Scheduling
Service-Oriented Computing: Semantics, Processes, Agents
August 2004
Strawman 2: Rigorous Scheduling
Hold read and write locks till end (no tickets)
Check that this prevents the bad example
The CTM must delay all commits until all actions are completed
possible only if allowed by LDB
requires an operation-level interface to LDB
Downside:
Causes all sites to be held up until all are ready to commit
Essentially like the 2PC approach
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
© Singh & Huhns

29. Service-Oriented Computing: Semantics, Processes, Agents
August 2004
Possible Methodology
When no cross-service constraints apply, local serializability is enough
Split data into local and shared partitions
LDB controls local data
CTM controls shared (local transactions can read, but write only via CTM)
Downside: doesn’t work in all cases
All shared data is managed through a special service
Only for the most trivial compositions
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
© Singh & Huhns

30. Compositional Atomicity
Service-Oriented Computing: Semantics, Processes, Agents
August 2004
Compositional Atomicity
Can succeed only if the services restrict their autonomy through service-level agreements, e.g., 2PC
Otherwise, the services
May not release their prepare-to-commit state
May not participate in a mutual commit protocol such as 2PC
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
© Singh & Huhns

31. Compositional Deadlock
Service-Oriented Computing: Semantics, Processes, Agents
August 2004
Compositional Deadlock
Assume LDB1 and LDB2 use 2PL. If a deadlock is formed
Solely of upper-level transactions, then the CTM may detect it
Of a combination of local and upper transactions, then
CTM won't know of it
LDBs won't share control information
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
© Singh & Huhns

32. Compositional Atomicity & Durability
Service-Oriented Computing: Semantics, Processes, Agents
August 2004
Compositional Atomicity & Durability
Without 2PC, what would happen when a CT fails?
Each service individually ensures “correctness” according to its local policies
Achieve weaker atomicity, durability via:
Redo: rerun the writes from log
Retry: rerun all of a subtransaction
Compensate: semantically undo all other subtransactions
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
© Singh & Huhns

33. Beyond ACID Transactions
Service-Oriented Computing: Semantics, Processes, Agents
August 2004
Beyond ACID Transactions
Composed services feature in business processes, which
Cross administrative boundaries
Are complex, i.e., long-running, failure-prone, multisite, with subtle consistency requirements
Cooperate with other processes, involving computational and human tasks
Respect autonomy and heterogeneity of components
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
© Singh & Huhns

34. Extended Transactions
Service-Oriented Computing: Semantics, Processes, Agents
August 2004
Extended Transactions
Extended transaction models relax the ACID properties by modifying various features
Allowing open nesting, wherein partial results are revealed (newer, non-ACID)
Atomicity, e.g., contingency procedures, to ensure “all”
Consistency restoration, e.g., via compensation, to ensure “none”
Constraints among subtransactions, such as
Commit dependencies
Abort dependencies
Ultimately, a transaction must be atomic (albeit in a relaxed sense)
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
© Singh & Huhns

35. Compensation
Something that semantically undoes the effect of a transaction
Common in business settings
Compensations are necessary even if imperfect
Deposit and withdraw
Reserve and cancel
Ship and return
Pay and refund
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

36. Extended Transaction Models
The ones we consider
Sagas
Flex Transactions
DOM Transactions
Several others, mostly either
Implementation-specific or
Narrower than the above
General-purpose scheduling approach (Chapter 14)
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

37. Sagas Guarantee atomicity but not isolation
Execute a sequence of transactions
If all transactions succeed, then good (all)
If any transaction fails, undo all previous in reverse order (none)
Assumptions
Compensations succeed (eventually) for the first several members of sequence
Retries succeed for the last several
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

38. Distributed Object Management
Avoid partial failure of a multitransaction via either total success or total failure
Total success
Redo from log
Retry
Contingency procedures
Total failure
Undo from log
Compensations
Uses ordering constraints and vital subtransactions
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns

39. Chapter 11 Summary
We need a means to ensure that services behave reasonably, i.e., by ensuring the integrity of data
Database management provides the notion of transactions for this purpose
Distributed transactions can apply in closed settings
Ensuring the ACID properties is infeasible in open settings
Extended transaction models are needed
Simple constructs of such models are helpful, and being encoded in standards
Often, an important application is process management (coming up)
More sophisticated behaviors require increased intelligence in modeling and enactment, also to be discussed later
Chapter 11
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns