1

Tapahtumanhallinnan pulmakohtia ja

ratkaisuja

TJT E54 – Kehittämismenetelmät ja arkkitehtuurit liiketoiminnassa

Kevät 2006Ville Seppänen <rissepp@cc.jyu.fi>

ACID

� Atomicity?� Consistency?� Isolation?� Durability?

2

Tapahtuman ominaisuudet:Jakamattomuus (atomicity)

� Tapahtuman järjestelmään tekemät muutokset vahvistetaan (commit) ainoastaan mikäli kaikki T:n operaariot onnistuvat. Muussa tapauksessa T keskeytetään (abort)

� Virheen sattuessa järjestelmään mahdollisesti tehdyt muutokset peruutetaan (roll-back, backward error recovery) siten, että järjestelmän alkuperäinen tila palautetaan lokitietojen perusteella

Tapahtuma vs. Operaatio?� Tapahtuma T = operaatiot t1, ..., tn� Esim 1.

� T = Siirretään 100 € tililtä A tilille B� t1 = Luetaan A:n saldo AS.� t2 = Kirjoitetaan AS = AS – 100 €� t3 = Luetaan B:n saldo BS� t4 = Kirjoitetaan BS = BS + 100 €

� Esim 2.� T = Käsitellään Teuvon tilaus koskien CD-levyä Musa

� t1 = Vähennetään Musa:n varastomäärää� t2 = Lähetetään Teuvolle Musa� t3 = Lähetetään Teuvolle lasku

3

Tapahtuman ominaisuudet:Johdonmukaisuus (consistency)

� T:n järjestelmän tilaan tekemien muutosten tulee vastata kuvatussa ilmiössä tapahtuvia muutoksia ja muutosten tulee tapahtua järjestelmän eheysvaatimusten (integrity constraints) rajoissa

� Useimmissa tapauksissa järjestelmä on väistämättä epäjohdonmukaisessa tilassa jossain T:n välivaiheessa. Eheys tarkastetaan tavallisesti vasta T:n pyytäessä vahvistusta (deferred integrity constraints)

Tapahtuman ominaisuudet:Johdonmukaisuus (consistency)

ACID ACIDState n State n+1 State n+2

abort abortcommit commit

read(A)write(A, (A-10))read(B)write(B, (B+10))

Temporary inconsistency

4

Tapahtuman ominaisuudet:Eriytyvyys (isolation)

� Järjestelmän samanaikaisesti suorittamat tapahtumat täytyy eristää toisistaan; ts. Ne eivät saa päästä käsiksi epäjohdonmukaisessa tilassa oleviin resursseihin (vrt. edellinen kalvo)

� Virheelliset tulokset� Ketjuuntuvat peruutukset (cascading rollback)� Sarjallistuvuusvaatimus (ei sarjallisen T:n tulos sama kuin jos

kunkin T:n operaatiot suoritettaisiin peräkkäin)

� Hallintakeinoina mm. optimistinensamanaikaisuuden hallinta, aikaleimaus, lukitusmenetelmät

� Sopiva menetelmä tapauskohtaisesti

Tapahtuman ominaisuudet:Eriytyvyys (isolation)

read(A)

write(A, (A+10))commit

read(A)write(A, (A+10))commit

read(A)read(B)

read(C)SUM=A+B+Ccommit

read(B)write(B, (B-10))read(C)write(C, (C+10))commit

read(A)write(A, (A+10))

abort

read(A)write(A, (A+10))commit

read(A)

read(A)commit

read(A)write(A, (A+10))commit

Update loss

Incorrect summary (A+B+C=100)

Inconsistent read

Dirty read

5

Tapahtuman ominaisuudet:Pysyvyys (durability)

� Tapahtuman järjestelmään tekemät muutokset eivät saa kadota tahattomasti tai tapaturmaisesti

Hajautettu tapahtumanhallinta

6

Kaksivaiheinen vahvistus(2-phase commit protocol)

� Atomic commitment protocol� An algorithm that ensures that all the processes

involved in a distributed transaction either commit or abort

� Coordination process� Responsible for controlling the overall atomicity� Controls the ’voting’

� A number of participating processes� Execute parts of a distributed transaction

Kaksivaiheinen vahvistus(2-phase commit protocol)

� Voting procedure – phase one� The coordinator sends vote requests to all

participants� When a participant receives the vote request, it

replies by voting either Yes or No, according to whether it is able to carry out the task

� Participants that voted Yes start waiting for a comfirmation message from the coordinator. Participants that voted No can unilateraly abort

7

Kaksivaiheinen vahvistus(2-phase commit protocol)

� Voting procedure – phase two� The coordinator collects all vote messages� If all the participants voted Yes the coordinator

decides to commit and sends Commit messages to all participants

� Otherwise, the coordinator decides to abort and sends Abort messages to all participants that voted Yes

� According to the received message, a participant decides to commit or abort

Kaksivaiheinen vahvistus(2-phase commit protocol)

� It is possible that messages may not arrive due to a failure and processes may be waiting forever: A timeout mechanism must be able to interrupt the waiting period

� In addition, the coordinator may attach the list of participants to the vote request message and thereby let the participants to know each other: Cooperative termination protocol

8

Cooperative termination protocol

� If participant p comes across the timeout while waiting for the Commit or Abort message from the coordinator, it can request this from the participant q

� If q has already decided to commit (or abort) it sends a Commit (or Abort) to p

� In the case that q has not voted yet it can decide to abort and send Abort to p

� If q has voted Yes but has not received the final Commit or Abort request from the coordinator it cannot help p in making the decision

Nested transactions

� A mechanism to facilitate transactions in distributed systems (Moss 1981)

� A tree-like model with parents, children, top-level (root), and leaves

9

Nested transactions

� Rules� A parent can spawn any number of children� Any number of children may be active

concurrently� Parent can’t access data when its children are

alive� A child can inherit a lock held by any ancestor� On child commit, its locks are inherited (anti-

inheritance) by parent

Nested transactions

� Rules, continued� Commit dependency: parent can commit only

after all its children terminate (commit/abort)� Abort dependency: On parent abort, even

updates of committed children are undone� Updates persist only if all ancestors commit

10

Nested transactions

Nested transactions

� Intra-transactional parallelism� Safe concurrency� Reduced response time

� Intra-transactional recovery control� Finer control of error handling� Improves availability

� System modularity� Composition of separately developed modules

11

Save points

� Can be seen as a check point in a transaction that forces the system to save the state of the running application and return a save point identifier for future reference

� Instead of removing an entire transaction after a failure of single operation (sub-process) backward recovery can return the last valid state of the transaction saved in the save point reference

Compensation & Sagas

� Long-living and distributed transactions are not reasonable to implement as a single ACID transaction� Keep the resources locked for the long periods of

time, which can significantly delay the commit of other simultaneously executed transactions

� Deadlock frequency grows with the fourth power of the transaction size

12

Compensation & Sagas

� Atomic commitment protocols ease the implementation of ACID transactions in distributed systems but futher transactions to become long living

� Backward recovery is expensive and difficult to implement

� The idea of compensating transactions (processes, operations) was introduced to simulate the transactional properties in such applications

Compensation & Sagas

� In Saga model (Garcia-Molina & Salem 1987) a long living transaction is broken up into a collection of subtransactions that interleave with other transactions� The results of a subtransaction can be made

immediately visible af ter it is committed

13

Compensation & Sagas

� Saga subtransactions can be executed independently but they must finally form an atomic unit� Should any of subtransactions fail the failed transaction is

aborted and already committed subtransactions are undone

� Removing the committed transaction means that results of subsequent transactions may become inconsistent and cause cascading rollbacks

� Instead of removing the results of failed transaction by using rollback the idea of compensating transaction is introduced

Compensation & Sagas

� Each Saga subtransaction Ti is provided with a compensating transaction Ci� If the compensation is not needed saga T1, T2, ..., Tn will

execute as a sequence of transactions� In case of compensation the sequence would be T1, T2, ...,

Tk, Ck, ..., C2, C1 where 0 � k < n, and Ck is a predefined compensating transaction of Ti

� A compensating transaction doesn’t necessarily restore the state that prevailed before the execution of Ti but rather undoes operation(s) of Ti from a semantic point of view

14

Compensation & Sagas� Contrary to traditional backward recovery

mechanism, which is based on compensating operations automatically deduced from the schedule, semantically compensating transactions may not be automatically generated� Even relatively simple actions (such as subtraction) must

follow the integrity constraints� Everything cannot be undone

� For example, ‘real actions’ with ‘real consequences’: impossible to undo but it may be possible to override the effect with a new action

� Committed acceptable & aborted acceptable termination states: ‘business considerations’

Forward recovery

� Combining the save points, compensation and recovery of failed transaction� Transaction that caused the failure is aborted

using the conventional rollback� Committed transactions are undone in reversed

order using their compensating counterparts until the save point is found (backward recovery)

� Finally, the transaction is restarted from the location of found save point (forward recovery)

15

Forward recovery

Save points

Forward recovery

� When recovering, it’s not always feasible or even possible to complete the transaction by trying to re-execute the original steps again

� However, it’s possible that the same objective can be achieved with different ways. Alternative methods of forward recovery should be considered during the process design phase

16

Transactional processes� Typical scenario: a top-level process consists of

subcomponents that are logically connected to the higherlevel process but are executed virtually independently

� A global transaction� a collage of all separate transactions that are included in

the process� often long-living and distributed

� Each global transaction can be divided into a set of local transactions� can be represented as a tree of hierarchically ordered

tasks, which may also include manual operations

Transactional processes

� The lowest level consists of DB ACID transactions

17

Transactional processes

Transactional processes