Transcript Chapter 11: Transaction Concepts

Chapter 11:
Transaction Concepts
Service-Oriented Computing: Semantics, Processes, Agents
– Munindar P. Singh and Michael N. Huhns, Wiley, 2005
Highlights of this Chapter

Basic concepts






Chapter 11
ACID properties
Schedules
Locking
Transactions over composed services
Relaxing serializability
Extended transaction models
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
2
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
3
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
4
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
5
ACID Properties


If programmers guarantee correctness of
individual transactions, then DBMS
guarantees correctness of any set of them
The ACID properties formalize the notion of a
transaction behaving as one operation

(Failure) Atomicity—all or none—if failed then no
changes to DB or messages




Chapter 11
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
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
6
Transaction Lifecycle
A transaction goes through well-defined
stages in its life (always terminating)


Inactive
Active (may read and write)





Chapter 11
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)
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
7
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



Two challenges


Chapter 11
Includes active transactions
Typically a partial order among events
What are the bad schedules?
How can the DBMS prevent them?
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
8
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:


Chapter 11
The final value of that item read by future
transactions
The value of the item as read by present
transactions
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
9
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
10
Serializable Schedules

Interleaved schedules are desirable


Those equivalent to some serial
schedule. Here equivalent can mean


Chapter 11
Why?
Conflict equivalent—all pairs of conflicting
ops are ordered the same way
View equivalent—all users get the same
view
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
11
Achieving Serializability


Chapter 11
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
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
12
Locks
Lock item x while using item x
 Binary: at most one party may lock x

Lock(x): acquire the lock



Chapter 11
Computation hangs until lock(x) returns, i.e., the lock is
acquired
Unlock(x): relinquish the lock
Gives mutual exclusion but restrictive
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
13
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)


Exclusive-lock(x) needed for write(x)


Chapter 11
Others can also hold a shared lock
No one else can concurrently hold a shared or
exclusive lock
Can be upgraded (read to write) or
downgraded (write to read)
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
14
Achtung!

By itself, using locks does not
guarantee serializability



Chapter 11
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
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
15
Two-Phase Locking (2PL)

Two phases in a transaction’s life




Guarantees serializability, but can deadlock
Strict 2PL releases all locks at once when the
transaction commits or rolls back



Chapter 11
Growing phase: acquire but not release locks
Shrinking phase: release but not acquire locks
Ensures rigorous schedules (to be discussed)
But can deadlock
Conservative 2PL: takes all locks early; risks
starvation
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
16
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
17
Recoverable Schedules
In which a transaction commits after all
transactions it read from have
committed

Chapter 11
In terms of the ACID properties, what is
the risk in allowing a nonrecoverable
schedule?
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
18
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


Chapter 11
Legal?
Expensive?
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
19
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
20
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
21
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
22
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
23
Transactions over Composed Services
Expedia
Composed Transaction Manager
United
service
LDB1
Direct
users
Composed
service as a
transaction
service
Sheraton
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
24
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:









Chapter 11
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
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
25
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


Downside:


Chapter 11
Make each composed transaction increment a
ticket at each site
Causes all local subtransactions of a transaction to
go through a local hotspot
Composed transactions are serialized, but only
because many are aborted!
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
26
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



Downside:


Chapter 11
possible only if allowed by LDB
requires an operation-level interface to LDB
Causes all sites to be held up until all are ready to
commit
Essentially like the 2PC approach
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
27
Possible Methodology


When no cross-service constraints apply, local
serializability is enough
Split data into local and shared partitions



Downside: doesn’t work in all cases


Chapter 11
LDB controls local data
CTM controls shared (local transactions can read,
but write only via CTM)
All shared data is managed through a special
service
Only for the most trivial compositions
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
28
Compositional Atomicity


Can succeed only if the services restrict
their autonomy through service-level
agreements, e.g., 2PC
Otherwise, the services


Chapter 11
May not release their prepare-to-commit
state
May not participate in a mutual commit
protocol such as 2PC
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
29
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


Chapter 11
CTM won't know of it
LDBs won't share control information
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
30
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:



Chapter 11
Redo: rerun the writes from log
Retry: rerun all of a subtransaction
Compensate: semantically undo all other
subtransactions
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
31
Beyond ACID Transactions

Composed services feature in business
processes, which




Chapter 11
Cross administrative boundaries
Are complex, i.e., long-running, failureprone, multisite, with subtle consistency
requirements
Cooperate with other processes, involving
computational and human tasks
Respect autonomy and heterogeneity of
components
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
32
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
33
Compensation



Something that semantically undoes the
effect of a transaction
Common in business settings
Compensations are necessary even if
imperfect




Chapter 11
Deposit and withdraw
Reserve and cancel
Ship and return
Pay and refund
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
34
Extended Transaction Models

The ones we consider




Several others, mostly either



Chapter 11
Sagas
Flex Transactions
DOM Transactions
Implementation-specific or
Narrower than the above
General-purpose scheduling approach
(Chapter 14)
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
35
Sagas


Guarantee atomicity but not isolation
Execute a sequence of transactions



Assumptions


Chapter 11
If all transactions succeed, then good (all)
If any transaction fails, undo all previous in
reverse order (none)
Compensations succeed (eventually) for
the first several members of sequence
Retries succeed for the last several
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
36
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
37
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



Chapter 11
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
Service-Oriented Computing: Semantics, Processes, Agents - Munindar Singh and Michael Huhns
38