Transaction Concepts ServiceOriented Computing Semantics Processes Agents Munindar P Singh and Michael N Huhns Wiley 2005 Chapter 11 2 ServiceOriented Computing Semantics Processes Agents ID: 425047
Download Presentation The PPT/PDF document "Chapter 11:" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Chapter 11:Transaction Concepts
Service-Oriented Computing:
Semantics, Processes, Agents
– Munindar P. Singh and Michael N. Huhns, Wiley, 2005Slide2
Chapter 112
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
Highlights of this Chapter
Basic concepts
ACID properties
Schedules
Locking
Transactions over composed services
Relaxing serializability
Extended transaction modelsSlide3
Chapter 113
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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?Slide4
Chapter 114
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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 interleavingSlide5
Chapter 115
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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 operationSlide6
Chapter 116
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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 foreverSlide7
Programmer-DBMS ContractIf each transaction is individually correct [programmer], then all transactions are jointly correct [DBMS]
Chapter 11
7
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael HuhnsSlide8
Chapter 118
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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)Slide9
Chapter 119
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
Schedules
Schedules are histories of computations showing all events of interest
Schedule of T
1
...T
n
has all ops of T
1
...T
n
in the same order as within each T
i
, but
interleaved
across T
i
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?Slide10
Chapter 1110
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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 transactionsSlide11
Chapter 1111
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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 correctSlide12
Chapter 1112
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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 viewSlide13
Chapter 1113
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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 realizedSlide14
Chapter 1114
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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 restrictiveSlide15
Chapter 1115
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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)Slide16
Chapter 1116
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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 relatedSlide17
Chapter 1117
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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 starvationSlide18
Chapter 1118
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
Reading From
T
1
reads from T
2
if the schedule contains a subsequence w
2
(x)...r
1
(x), where
w
2
is the first write on x going backwards from r
1
(x)
a
2
doesn’t occur between w
2
and r
1Slide19
Chapter 1119
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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?Slide20
Chapter 1120
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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?Slide21
Chapter 1121
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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 imageSlide22
Chapter 1122
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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 schedulesSlide23
Chapter 1123
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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 DBMSSlide24
Chapter 1124
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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 intermediate
results are not exposed till the global transaction commits
As in WS-
AtomicTransaction
Why would ACID transactions ever be useful for SOC?Slide25
Chapter 1125
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
Transactions over Composed Services
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
Composed Transaction Manager
LDB1
LDB2
service
service
Composed service as a transaction
Direct
users
United
Sheraton
ExpediaSlide26
Chapter 1126
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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 T
1
: r
1
(a); r
1
(c)
CTM does T
2
: r
2
(b); r
2
(d)
LDB1 does T
3
: w
3
(a); w
3
(b)
LDB2 does T
4
: w
4
(c); w
4
(d)
Since T
1
and T
2
are read-only, they are serializable.
LDB1 sees S
1
=r
1
(a); c
1
; w
3
(a); w
3
(b); c
3
; r
2
(b); c
2
LDB2 sees S
2
=w
4
(c); r
1
(c); c
1
; r
2
(d); c
2
; w
4
(d); c
4
Each LDB has a serializable schedule; yet jointly they put T
1
before and after T
2
Notice we would have lots of potential compositions, so the problem is worseSlide27
Chapter 1127
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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!Slide28
Chapter 1128
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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 approachSlide29
Chapter 1129
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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 compositionsSlide30
Chapter 1130
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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 2PCSlide31
Chapter 1131
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
Compositional Deadlock
Assume LDB
1
and LDB
2
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 informationSlide32
Chapter 1132
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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
subtransactionsSlide33
Chapter 1133
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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 componentsSlide34
Chapter 1134
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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)Slide35
Chapter 1135
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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 refundSlide36
Chapter 1136
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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)Slide37
Chapter 1137
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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 severalSlide38
Chapter 1138
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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
subtransactionsSlide39
Chapter 1139
Service-Oriented Computing: Semantics, Processes, Agents
- Munindar Singh and Michael Huhns
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