WS Technologies III Transactions
description
Transcript of WS Technologies III Transactions
![Page 1: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/1.jpg)
1
WS Technologies IIITransactions
Roberto BruniDipartimento di Informatica Università di Pisa
Models and Languages for Coordination and Orchestration
IMT- Institutions Markets Technologies - Alti Studi Lucca
![Page 2: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/2.jpg)
2
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Contents Orchestration and Choreography WSFL Transactions and Compensations BPEL4WS
![Page 3: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/3.jpg)
3
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Motivation I A top-ranked global management issue in IT:
"connecting to customer, suppliers and partners electronically"
WS Orchestration / Choreography is about providing an open, standard-based approach for connecting WS together to create high-level business process
executable, abstract, collaborative, reusable reducing complexity, time-to-market, costs increasing efficiency, scalability, adaptability,
accuracy
![Page 4: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/4.jpg)
4
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Motivation II Orchestrated WS that are long-running must
also manage exceptions
how the system will respond to faults (when building business process, nearly 80% of time is spent
in exception management!)
transactional integrity to reach mutually agreed outcomes ACID-based is not ok for long-running transactions compensating transactions are more appropriate Not dealt with in WSFL!
![Page 5: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/5.jpg)
5
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Transactions and All the Rest
We shall survey classic aspects of transactions commitment protocols (postponed after
Easter) compensations WS challenges
![Page 6: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/6.jpg)
6
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Concurrency Control and Recovery in DataBase Systems
Concurrency control is the activity of coordinating the actions of
processes that operate in parallel, access shared data, and therefore potentially interfere with each other
Recovery is the activity of ensuring that Sw and Hw failures
do not corrupt persistent data Transaction
is a sequence of actions on a shared database The goal is to ensure that transactions
execute atomically (no interference)
![Page 7: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/7.jpg)
7
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
DataBase Systems State
Set of named data items with values Main operations
Read(x) – query – returns the value of the data item x
Write(x,v) – update – sets the data item x to value v We abstract from the granularity of data items
Words in main memory Pages of a disk Records in a file Fields of a record
![Page 8: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/8.jpg)
8
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Execution Operations should be executed sequentially, but
some operations can be executed concurrently The final effect must be the same of some sequential
execution
1. Read(x)2. Write(x,1) | Read(y)3. Write(y,0)
The order is inessential
![Page 9: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/9.jpg)
9
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Transaction Primitives Start
begin a new transaction assign a unique transaction identifier
Commit successfully terminate the transaction its effects are made permanent
Abort invoke the abnormal termination of the
transaction its effects are obliterated can be imposed by failures
![Page 10: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/10.jpg)
10
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Terminology Unique entry / exit points
a transaction is defined by a Start operation, followed by a possibly concurrent execution of (Read / Write) operations followed by either a Commit or Abort
Committed transactions Aborted transactions Active transactions
started but not yet committed (or aborted) Uncommitted transactions
active or aborted
![Page 11: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/11.jpg)
11
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Database Transactions Sequences of operations / actions
which preserve database consistency ACID properties:
Atomicity Consistency Isolation Durability
Transaction’s changes to the states are ATOMIC:• either all happen• or none happen
![Page 12: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/12.jpg)
12
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Database Transactions Sequences of operations / actions
which preserve database consistency ACID properties:
Atomicity Consistency Isolation Durability
A transaction is a correct transformation of the state: its actions, taken as a group, do not violate any integrity constraint associated with the states
![Page 13: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/13.jpg)
13
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Database Transactions Sequences of operations / actions
which preserve database consistency ACID properties:
Atomicity Consistency Isolation Durability
Transactions can be executed concurrently, but it appears to each transaction T that others are executed either before T or after T
![Page 14: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/14.jpg)
14
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Database Transactions Sequences of operations / actions
which preserve database consistency ACID properties:
Atomicity Consistency Isolation Durability
Once a transaction successfully commits, its changes to the states survive failures
![Page 15: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/15.jpg)
15
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Database Transactions
Sequences of operations / actions which preserve database consistency
ACID properties: Atomicity Consistency Isolation Durability
Interest on serializability any T1|…|Tn can be seen as Ti1;…;Tin
![Page 16: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/16.jpg)
16
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Recoverability When T aborts, its effects are wiped out
Effects on data (updates) undo
restore the original value as if T never executed Effects on each T’ which read values
updated by T (dependencies) cascading aborts
each T’ must be aborted but remember that committed transactions cannot be
aborted delaying commits can be necessary to ensure
recoverability
![Page 17: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/17.jpg)
17
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Recoverability: Example
T1: Start1
…Write1(x,2)…Abort1
T2: Start2
…Read2(x)…Write2(y,3)…Commit2
T1|T2:…Write1(x,2) …Read2(x)…Write2(y,3)…Commit2
…Abort1
1. When T1 aborts, Write1(x,2) must be undone
2. Undoing Write1(x,2) can compromise T2 that read from x
3. But T2 did already commit…it should have been delayed!
![Page 18: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/18.jpg)
18
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Avoiding Cascading Aborts Cascading aborts are unpleasant, but
often necessary to ensure recoverability Require bookkeeping of dependencies Uncontrollably many transactions might be
forced to abort Not necessary if every transaction reads
values written by committed transactions Delay Readi(x) until all transactions that
issued Writek(x,v) are either aborted or committed
![Page 19: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/19.jpg)
19
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Strict Execution When undoing Write(x,v)
which value should be restored? the initial value? but other transactions can have issued Write(x,v’)
Before image the value of x just before the operation to be undone
Later overwritten values should not be updated Delay Writei(x,v) until all transactions that
issued Writek(x,w) are either aborted or committed
![Page 20: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/20.jpg)
20
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Why Strict Execution: Example
…Write1(x,1)Write1(y,3)Write2(y,1)Commit1
Read2(x)Abort2
When T2 aborts, the value of y should be 3 (the before image)
…Write1(x,2)Write2(x,3)Abort1
Suppose initially x=1. When T1 aborts, the value of x should be 3 not 1
…Write1(x,2)Write2(x,3)Abort1
Abort2
The before image of T2 is not meaningful after T1 aborts
![Page 21: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/21.jpg)
21
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Non-Recoverable Interactions
It is not always possible to reverse effects e.g. input / output statements
Deferred output approach output messages of T only after T
commits not always feasible
(user input might depend on output messages)
![Page 22: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/22.jpg)
22
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
More on Serializability When two transactions execute
concurrently, their operations are interleaved Even if they commit, interference can cause
incorrect results Lost updates Inconsistent retrieval
Avoid interleaving at all correct but inefficient
Restrict to serializable executions
![Page 23: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/23.jpg)
23
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Lost Updates: ExampleT_Deposit(a,n):Startt:=Read(a)t:=t+nWrite(a,t)Commit
T_Deposit(a,10) | T_Deposit(a,20) :Start1
Read1(a) // returns vStart2
Read2(a) // returns the same vWrite1(a,v+10)Write2(a,v+20)Commit2
Commit1
At the end the account is increased by 20 (not by 30 as in any serial execution)
![Page 24: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/24.jpg)
24
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Inconsistent Retrieval: Example
T_Transfer(£,$,n):Starts:=Read(£)s:=s-nWrite(£,s)t:=Read($)t:=t+n*rate[£,$]Write($,t)Commit
T_Transfer(a,b,5)|T_Total(a,b):Start1
Read1(a) // returns vStart2
Read2(a) // returns the same vWrite1(a,v-5)Read1(b) // returns wWrite1(b,w+5*r)Read2(b) // returns w+5*rCommit2
Commit1
The output does not correspond to the total amount
T_Total(£,$):Starts:=Read(£)t:=Read($)t:=t+s*rate[£,$]output(t)Commit
![Page 25: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/25.jpg)
25
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
DataBase System Model I Transaction Manager (TM)
receives requests for transactions and operations forwards them to the scheduler
Scheduler controls the relative order of execution
Recovery Manager (RM) responsible for commits and aborts
Distributed Architecture sites connected by a network
![Page 26: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/26.jpg)
26
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
DataBase System Model II
TM
Sched
RM
Network
…
DB
TM
Sched
RM
DB
TM
Sched
RM
DB
TM
Sched
RM
DB
![Page 27: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/27.jpg)
27
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Some ACID Variations I Flat Transactions
Traditional model, strictly meets ACID properties Not adequate to model complex situations
A task’s abort causes all activities to be rolled back Flat with Savepoints
Introduces programmable savepoints Rollback command restore savepoints without aborting Transactions can be rolled back individually
Chained transactions Add savepoints via the chain operation
Commits and start a new transaction with same locks
![Page 28: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/28.jpg)
28
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Some ACID Variations II Nested Transactions
Hierarchical tree of transactions Top-level is ACID Other nodes are ACI (subtransactions)
If a parent aborts all its children abort (even if committed)
If a subtransaction aborts its parent can still commit A subtransaction commit is seen outside only when
its parent commits (protected nested transactions) The structure can exploit parallelism within
transactions Localize failures to subtransactions
![Page 29: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/29.jpg)
29
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Some ACID Variations III Multi-level Transactions
Nested transaction that allow pre-commits to export partial results to other
transactions at the same level perfect compensations to abort after pre-commit
Abstraction layers Operations at level n are implemented using
operations of the lower level immediately below no shortcuts
![Page 30: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/30.jpg)
30
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Some ACID Variations IV Distributed Transactions
Flat but executed in a distributed environment Partitioned in sub-transactions on network’s nodes
Decomposition reflects neither the hierarchical structure of the application, nor its functional structure
Decomposition depends on data distribution over the nodes
Decisions made by a sub-transaction affect the entire transaction
Commit protocols are needed All these models are traditional ones
see e.g. [Gray, Reuter 1993]
![Page 31: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/31.jpg)
31
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Some Non ACID Flavors I Long-Lived Transactions (LLT)
Execution takes a considerable amount of time
hours, days, weeks, … Not possible to block all short transactions
Open Nested Transactions [Gray 1981] Compensations are not perfect Relaxed multi-level
No abstraction layers Shortcuts are allowed
![Page 32: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/32.jpg)
32
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Some Non ACID Flavors II Sagas [Garcia-Molina, Salem 1987]
Special case of open-nested Only two levels of nesting
LLT broken in a non-atomic sequence of ACID sub-transactions T1…Tn
Each Ti has a (non-perfect) compensation Ci
Partial execution of the sequence are undesirable If it cannot be completed, then must be compensated
Executed as either T1…Tn or T1…TkCk…C1
Partial effects are visible to other transactions no notification / compensation to siblings
![Page 33: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/33.jpg)
33
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Some Non ACID Flavors III Flexible [Elmagarmid et al. 1990]
Same task implemented by different (functionally equivalent) sub-transactions
Programmable failure / success dependencies T1: Rent a car from AVIZ T2: Rent a car from HERTS if T1 fail
Pre-committed actions and compensations Mixed (with or without compensations) transactions
coexist within a single global transaction Incorporates time for flexible scheduling
![Page 34: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/34.jpg)
34
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Some Non ACID Flavors IV Split and Join Transactions [Pu et al. 1988]
Open-ended activities Long-running, not foreseeable concurrent interactions
Computer-Aided Design/Computer-Aided Manufacturing
Editing and Sw development Split command
Divide a running transaction in two independent ones Can export results, release/share resources
Join command Merges two running transactions into one All resources become shared Results are visible only after the commit of the joint
transaction
![Page 35: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/35.jpg)
35
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Some Non ACID Flavors V Multi-Transactions
To be used in distributed objects systems with heterogeneous databases
Complex transactions by composing building blocks (as needed by applications)
Mixture of flat, nested, open-nested are possible
Countermeasure, Retriable, Timed, …
![Page 36: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/36.jpg)
36
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Transactions in GC? ACID would generate too many aborts Local consistency vs global consistency Asynchronous commit Heterogeneous policies Several entry / exit points Messages in place of shared data Dynamic topology of the network Mobility For an overview:
"A framework for analyzing mobile transaction models" A. Coratella, M. Felder, R. Hirsch, E. Rodriguez (Journal of DataBase Management 12(13), 2001)
![Page 37: WS Technologies III Transactions](https://reader035.fdocuments.net/reader035/viewer/2022062722/56813ad7550346895da3180e/html5/thumbnails/37.jpg)
37
Roberto Bruni @ IMT Lucca 23 March 2005
Models and Languages for Coordination and Orchestration
InstitutionsMarketsTechnologies
IMT
Some References Concurrency control and recovery in
database systems (Addison-Wesley 1987) P. Bernstein, N. Goodman, V. Hadzilacos
Transaction processing: concepts and techniques (Morgan Kaufmann 1993) J. Gray, A. Reuter
Sagas (Proc. SIGMod’87, ACM, pp. 249-259) H. Garcia-Molina, K. Salem