TRANSACTION & CONCURRENCY CONTROL
TRANSACTION & CONCURRENCYCONTROL1
CONTENTTransactions & Nested transactionsMethods for concurrency controlLocksOptimistic concurrency controlTimestamp orderingDistributed TransactionsDistributed Deadlock2
TRANSACTION & NESTED TRANSACTIONTransaction: specified by a client as a set ofoperations on objects to be performed as anindivisible unit by the servers managed thoseobjects.Goal of transaction: ensure all the objectsmanaged by a server remain in a consistent statewhen accessed by multiple transactions and in thepresence of server crashes.3
Transaction Sequence of operations that forms a single step,transforming the server data from one consistent stateto another. All or nothing principle: a transaction either completessuccessfully, and the effects are recorded in the objects, or it hasno effect at all. (even with multiple clients, or crashes) A transactions is indivisible (atomic) from the point ofview of other transactionsNo access to intermediate results/states of other transactions Free from interference by operations of other transactions But Transactions could run concurrently, i.e., with multipleclients Transactions may be distributed, i.e., across multipleservers
Transaction FailureModesTransaction:A failure at thesepoints means thecustomer losesmoney; we needto restore old stateThis is the point ofno return1. savings.deduct(100)2. checking.add(100)3. mnymkt.deduct(200)4. checking.add(200)5. checking.deduct(400)6. dispense(400)7. commitA failure atthese pointsdoes not causelost money, butold stepscannot berepeatedA failure after thecommit point(ATM crashes)needs correctiveaction; no undoingpossible.
TRANSACTION & NESTED TRANSACTIONTransaction applies to recoverableobjects and intended to be atomic(atomic transaction):Recoverable objects: objects can berecovered after their server crashes.Atomic operations: operations that arefree from interference from concurrentoperations being performed in the otherthreads.6
Distributed TransactionA distributed transaction accesses resource managersdistributed across a networkWhen resource managers are DBMSs we refer to thesystem as a distributed database systemDBMSat Site 1ApplicationProgramDBMSat Site 27
Transactions (ACID) Atomic: All or nothing. No intermediate states arevisible. Consistent: system invariants preserved. Isolated: Two transactions do not interfere witheach other. They appear as serial executions. Durable: The commit causes a permanent change.88
TRANSACTION & NESTED TRANSACTIONMaximize concurrency: transactions areallowed to execute concurrently if they wouldhave the same effect as a serial execution serially equivalent.Cases of transaction failing:Service actions related to process crashes.Client actions related to server process crashes.9
Concurrency Control IssuesLost Update ProblemsInconsistent Retrievals ProblemsSerial EquivalenceConflicting Operations10
Lost Update ProblemTransactionT :TransactionU:balance w(balance/10)balance w(balance/10)balance b.getBalance(); 200balance b.getBalance(); 200b.setBalance(balance*1.1); 220b.setBalance(balance*1.1); 220a.withdraw(balance/10) 80c.withdraw(balance/10) 280Accounts A, B, C has initial balance of 100, 200 & 300.Transaction T transfers amounts from A to B. Transaction U transfersamounts from C to B. in both cases, amount transfer is calculated toincrease balance by 10%.The net effect should be 242. but U’s update is lost, T overwrite it withoutseeing it. Both reads the old values.11
The inconsistent retrievals deposit(100)aBranch.branchTotal()a.withdraw(100); 100total a.getBalance() 100total total b.getBalance() 300total total c.getBalance()b.deposit(100) 300-Transaction V transfer a sum from account A to B & W invokes the branch totalmethod to obtain sum of balances to all accounts.-Balance of both A & B has initially 200. the result of branch total includes sumof A & B as 300 is wrong.-W’s retrieval is inconsistent because V has performed only withdrawal part of atransfer at the time the sum is calculated.
A serially equivalent interleaving of Tand UTransactionT:TransactionU:balance balance/10)balance balance/10)balance b.getBalance() 200b.setBalance(balance*1.1) 220balance b.getBalance() 220b.setBalance(balance*1.1) 242a.withdraw(balance/10) 80c.withdraw(balance/10) 278
Serial Equivalence InterleavingAn interleaving of the operations of transaction in whichthe combined effect is the same as if the transactions hadbeen performed one at a time in some order is a seriallyequivalent interleaving.Use of serial equivalence as a criterion for a correctconcurrent execution prevents the occurrence of lostupdate problem and inconsistent retrieval problem.14
A serially equivalent interleaving of Vand it(100)aBranch.branchTotal()a.withdraw(100); 100b.deposit(100) 300total a.getBalance() 100total total b.getBalance() 400total total c.getBalance().15
Read and write operation conflict rulesOperations of different sonBecause the effect of a pair of read operationsdoes not depend on the order in which they areexecutedYes Because the effect of a read and a write operationdepends on the order of their executionYes Because the effect of a pair of write operationsdepends on the order of their executionNoFor two transaction to be serially equivalent, itis necessary and sufficient that all pairs ofconflicting operations of the two transactions beexecuted in the same order at all of the objectsthey both access.16
TRANSACTION & NESTED TRANSACTIONRecoverability from abortsProblems with aborting:Dirty readPremature writesSolutions:Recoverability of transactionsAvoid cascading abortsStrict execution of transactions17
A dirty read when transaction T aborts-Recoverability from Aborts: Server must records theeffects of all committed transactions and none of theeffects of aborted transactions. Transactions may abort bypreventing it affecting other concurrent transaction if itdoes so.-Dirty read: the isolation property of transactions requirethat transactions do not see the uncommitted state ofother transactions.-The dirty read problem is caused by the interactionbetween a read operation in one transaction and anearlier write operation in another transaction on thesame object.18
A dirty read when transaction T abortsTRANSACTION TTRANSACTION Ua.getBalance( );a.setBalance(balance 10);a.getBalance( );a.setBalance(balance 20);balance a.getBalance( );a.setBalance(balance 10); 100 110balance a.getBalance( );a.setBalance(balance 20);commit transaction; 110 130abort transaction;-Now suppose that the transaction T aborts after U has committed. Thenthe transaction U will have seen a value that never existed, since A will berestored to its original value. Hence transaction U has performed a dirtyread. As it has committed and cant be undone.19
A dirty read when transaction T aborts-Recoverability of transactions: any transaction like U, that isin danger of having a dirty read delays its commit operationuntil after the commitment of any other transaction whoseuncommitted state has been observed. Eg: U delays itscommit until after T commits.- Cascading aborts: the aborting of any transactions maycause further transactions to be aborted transactions areonly allowed to read objects that were written by committedtransactions.-Any read operations must be delayed until othertransaction that applied a written operation to the sameobject have committed or aborted.20
Premature Writes leading dirty readTransaction TTransaction U 100a.setBalance(105) 105a.setBalance(110) 110Some DBs implement the action of abort by restoring “before image” ofall the writes of a transaction.The two executions are serially equivalent if the transaction U abortsand T commit. The balance should be 105A 100 is the before image of T’s write. 105 is the before image of U’swrite. If U commits and T-Aborts, the before image is 100. we getwrong balance of 100Solution: Write operations must be delayed until earlier transaction that21updated the same objects have either committed or aborted
Nested transactionT: top-level transactionT1 openSubTransactionT2 v.commitT21122
NESTED TRANSACTIONThe outermost transaction in a set of nestedtransactions is called the top-level transaction.Transaction other than the top-level transaction arecalled sub-transaction.Any sub-transaction appears atomic to its parent withrespect to failures.Sub-transaction at the same level can run concurrentlybut their access to common objects is serialized.23
NESTED TRANSACTIONEach sub-transaction can fail independently of itsparent and of the other sub-transaction.When a sub-transaction aborts, the parenttransaction can sometimes choose an alternativesub-transaction to complete its task.If all the tasks is done on same level, then it iscalled flat transaction.24
TRANSACTION & NESTED TRANSACTIONAdvantages of nested transaction:Sub-transaction at one level (and descendent)may run concurrently with other subtransaction: Additional concurrency in atransaction. If sub-transactions run in differentservers, they can work parallel.Subtransactions can commit or abortindependently25
NESTED TRANSACTIONRules for commitment of nested transactions:Transactions commit/abort only after its child havecompleted.After completing, subtransaction makes independentdecision either to commit provisionally or to abort.When a parent aborts, all of its subtransactions areaborted.When a subtransaction aborts, parent can decidewhether to abort or not.Top-level transaction commits all of theprovisionally committed subtransactions can committoo (provided none of their ancestor has aborted).26
Schemes for Concurrency controlLockingServer attempts to gain an exclusive ‘lock’ that isabout to be used by one of its operations in atransaction.Can use different lock types (read/write forexample)Two-phase lockingOptimistic concurrency controlTime-stamp based concurrency control27Transactions
METHOD FOR CONCURRENCY CONTROLLock:Server attempts to lock any object that is about to use byclient’s transaction.Requests to lock objects are suspended and wait until theobjects are unlocked.Serial equivalence: transaction is not allowed any new locksafter it has release a lock.Two-phase lock: growing phase (new locks are acquired), shrinkingphase (locks are released).Strict execution: locks are held until transactioncommits/aborts (Strict two-phase locking).Recoverability: locks must be held until all the objects itupdated have been written to permanent storage.28
METHOD FOR CONCURRENCY CONTROLLock:Simple exclusive lock reduces concurrency locking scheme for multiple transaction reading anobject, single transaction writing an object.Two types of locks used: read locks (shared lock) &write locks.Operation conflict rules:Request for a write lock is delayed by the presence of aread lock belonging to another transaction.Request for either a read/write lock is delayed by thepresence of a write lock belonging to another transaction.29
Transaction T and U with exclusive locks.TRANSACTION TTRANSACTION Ubalance b.getBalance( ;balance b.getBalance( ;openTransactionbalance b.getBalance( ); lock lock AopenTransactionbalance b.getBalance( );closeTransactionunlock A,B b.setBalance(balance*1.1);c.withdraw(balance/10) ;closeTransaction wait forT’lock on Block Block Cunlock B,CAssumption: balance of ABC are not yet locked when transaction Tand U starts.When T starts using B, then it is locked for B. subsequently when Ustarts using B, it is still locked for T and so U waits. When Tcommitted, B is unlocked and C resumes : effective serialization30
Two-Phase Locking (1)In two-phase locking, a transaction is not allowed to acquireany new locks after it has released a lockTransactions31
Strict Two-Phase Locking (2) Strict two-phase locking.Transactions32
Use of locks in strict two-phaselocking1. When an operation accesses an object within a transaction:(a) If the object is not already locked, it is locked and the operationproceeds.(b) If the object has a conflicting lock set by another transaction, thetransaction must wait until it is unlocked.(c) If the object has a non-conflicting lock set by another transaction,the lock is shared and the operation proceeds.(d) If the object has already been locked in the same transaction, thelock will be promoted if necessary and the operation proceeds.(Where promotion is prevented by a conflicting lock, rule (b) isused.)2. When a transaction is committed or aborted, the server unlocks all objectsit locked for the transaction.Transactions33
Lock compatibilityFor one objectReadLock already setnonereadwriteOKOKWaitLock requestedWriteOKwaitwait34
METHOD FOR CONCURRENT CONTROLLocking rule for nested transactions:Locks that are acquired by a successfulsubtransaction is inherited by its parent &ancestors when it completes. Locks held untiltop-level transaction commits/aborts.Parent transactions are not allowed to runconcurrently with their child transactions.Subtransactions at the same level are allowedto run concurrently.35
Method for concurrent controlDeadlock:Definition: A state in which each member of a groupof transactions is waiting for some other memberto release a lock.Prevention:Lock all the objects used by a transaction when itstarts not a good way.Request locks on objects in a predefined order premature locking & reduction in concurrency.36
METHOD FOR CONCURRENT CONTROLDeadlock:Detection: Finding cycle in a wait-for graph select atransaction for aborting to break the cycle.Choice of transaction to be aborted is not simple.Timeouts: each lock is given a limited period in which it isinvulnerable.Transaction is sometimes aborted but actually there is no deadlock.If we use locking to implement concurrency control intransactions, we can get deadlocks (even within a single server)So we need to discuss:Deadlock detection within a single systemDistributed deadlock37
Deadlock detectionA deadlock occurs when there is a cycle in thewait-for graph of transactions for locksThere may be more than oneResolve the deadlock by aborting one of thetransactions .E.g. the youngest, or the one involved in morethan one cycle, or can even use “priority” .38COMP28112 Lecture 124-Jul-21
A cycle in a wait-for graphHeld byWaits forATUWaits for39UTBHeld by
METHOD FOR CONCURRENCY CONTROLDrawbacks of locking:Lock maintenance represents an overhead that isnot present in systems that do not supportconcurrent access to shared data.Deadlock. Deadlock prevention reducesconcurrency. Deadlock detection or timeout notwholly satisfactory for use in interactive programs.To avoid cascading aborts, locks cant be releaseduntil the end of the transaction.This may reducesignificantly the potential for concurrency.40
METHOD FOR CONCURRENT CONTROLOptimistic concurrency control:Is an alternative optimistic approach to theserialization of transactions that avoids thedrawbacks of locking.Idea: in most applications, the likelihood of twoclients transactions accessing the same object islow.Transactions are allowed to proceed as thoughthere were no possibility of conflict with othertransactions until the client completes its task andissues a close-Transaction request.41
METHOD FOR CONCURRENT CONTROLOptimistic concurrency control:Each transaction has the following 3 phases:Working phase: each transaction has a tentative versionof each of the objects that it updates.Validation phase: Once transaction is done, thetransaction is validated to establish whether or not itsoperations on objects conflict with operations of othertransactions on the same object. If not conflict, cancommit; else some form of conflict resolution is neededand the transaction may abort.Update phase: changes in tentative versions are madepermanent if transaction is validated42
METHOD FOR CONCURRENT CONTROLOptimistic concurrency control:Validation of transactions: use the read-writeconflict rules to ensure that the scheduling of atransaction is serially equivalent with respect to allother overlapping transactions.Backward validation: check the transactionundergoing validation with other preceding overlappingtransactions (enter the validation phase before).Read set of the transaction being validated is compared withthe write sets of other transactions that have alreadycommitted.Forward validate: check the transaction undergoingvalidation with other later transactionsWrite set of the transaction being validated is compared withthe read sets of other overlapping active transactions (still inworking phase).43
Validation of transactionsWorkingValidation UpdateT1Earlier committedtransactionsT2T3Transactionbeing validatedTvactive1Later activetransactions44active2Transactions
45
46
Schemes for Concurrency controlTime-stamp based concurrency controlEach transaction is assigned a unique timestamp atthe moment it startsIn distributed transactions, Lamport’s timestamps can beusedEvery data item has a timestampRead timestamp timestamp of transaction that last readthe itemWrite timestamp timestamp of transaction that mostrecently changed an item47Transactions
METHOD FOR CONCURRENT CONTROLTimestamp ordering:Basic timestamp ordering rule:A transaction’s request to write an object is valid only if thatobject was last read and written by earlier transactions. Atransaction’s request to read an object is valid only if thatobject was last written by an earlier transactionsTimestamp ordering write rule:if (Tc maximum read timestamp on D &&Tc write timestamp on committed version of D)perform write operation on tentative version of D withwrite timestamp Tcelse /*write is too late*/abort transaction Tc48
METHOD FOR CONCURRENT CONTROLTimestamp ordering read rule:If (Tc write timestamp on committed version of D){ let Dselected be the version of D with the maximum writetimestamp Tcif (Dselected is committed)perform read operation on the version Dselectedelsewait until the transaction that made version Dselectedcommits or aborts then reapply the read rule}Elseabort transaction Tc49
Distributed TransactionsMotivationProvide distributed atomic operations at multipleservers that maintain shared data for clientsProvide recoverability from server crashesPropertiesAtomicity, Consistency, Isolation, Durability (ACID)Concepts: commit, abort, distributed commit50Transactions
Distributed Transactions(a) Flat transaction(b) Nested transactionsMXT11XClientTYTT1NT 12TT21T2ClientYPZT2251Transactions
Nested banking Cc.deposit(10)T4Dd.deposit(20)T1TYT Transaction52T2ZTransactions
Concurrency Control for DistributedTransactionsGeneral organization ofmanagers for handlingdistributed transactions.53Transactions
A distributed banking icipantA.a.withdraw(4);joinBranchXTClientT thdraw(T, 3);BBranchYjoinparticipantNote: the coordinator is in one of the servers, e.g. d.deposit(3);BranchZ
Concurrency Control for DistributedTransactionsLockingDistributed deadlocks possibleTimestamp orderingLamport time stampsfor efficiency it is required that timestampsissued by coordinators be roughlysynchronized55Transactions
Distributed DeadlockWithin a single server, allocating and releasing lockscan be done so as to maintain a wait-for graph whichcan be periodically checked.With distributed transactions locks are held indifferent servers – and the loop in the entire wait-forgraph will not be apparent to any one serverOne solution is to have a coordinator to which eachserver forwards its wait-for graphBut centralised coordination is not ideal in adistributed system56COMP28112 Lecture 124-Jul-21
Distributed deadlock(a)(b)WHeld byDCAXZWaitsforWWaits forVHeldbyHeld byVUWaits forBHeldbyY57TransactionsU
Local and global wait-for graphslocal wait-for graphTUX58local wait-for graphVglobal deadlock detectorTTUYTransactionsV
Atomic Commit ProtocolsThe atomicity of a transaction requires thatwhen a distributed transaction comes to anend, either all of its operations are carried outor none of themTwo phase commit (2PC)Covered In CH-9Three Phase Commit (3PC)Recovery . .Repeated .Transactions59
The two-phase commit protocol - 1Phase 1 (voting phase):1. The coordinator sends a canCommit?(VOTE REQUEST) request to each of theparticipants in the transaction.2. When a participant receives a canCommit?request it replies with its vote Yes(VOTE COMMIT) or No (VOTE ABORT) tothe coordinator. Before voting Yes, it prepares tocommit by saving objects in permanent storage.If the vote is No the participant abortsimmediately.60Transactions
The two-phase commit protocol - 2Phase 2 (completion according to outcome of vote):3. The coordinator collects the votes (including its own).(a) If there are no failures and all the votes are Yes thecoordinator decides to commit the transaction andsends a doCommit (GLOBAL COMMIT) request toeach of the participants.(b)Otherwise the coordinator decides to abort thetransaction and sends doAbort (GLOBAL ABORT)requests to all participants that voted Yes.4. Participants that voted Yes are waiting for a doCommit ordoAbort request from the coordinator. When a participantreceives one of these messages it acts accordingly and in thecase of commit, makes a haveCommitted call as confirmationto the coordinator.61Transactions
Communication in two-phase commitprotocolCoordinatorParticipantstep statusstep status13prepared to commit(waiting for votes)committedcanCommit?Yes2prepared to ne62Transactions
Operations for two-phase commitprotocolcanCommit?(trans)- Yes / NoCall from coordinator to participant to ask whether it can commit a transaction.Participant replies with its vote.doCommit(trans)Call from coordinator to participant to tell participant to commit its part of atransaction.doAbort(trans)Call from coordinator to participant to tell participant to abort its part of atransaction.haveCommitted(trans, participant)Call from participant to coordinator to confirm that it has committed thetransaction.getDecision(trans) - Yes / NoCall from participant to coordinator to ask for the decision on a transaction afterit has voted Yes but has still had no reply after some delay. Used to recoverfrom server crash or delayed messages.63Transactions
Two-Phase Commit protocol - 3actions by coordinator:while START 2PC to local log;multicast VOTE REQUEST to all participants;while not all votes have been collected {wait for any incoming vote;if timeout {write GLOBAL ABORT to local log;multicast GLOBAL ABORT to all participants;exit;}record vote;}if all participants sent VOTE COMMIT and coordinator votes COMMIT{write GLOBAL COMMIT to local log;multicast GLOBAL COMMIT to all participants;} else {write GLOBAL ABORT to local log;multicast GLOBAL ABORT to all participants;}Outline of the steps taken by the coordinator in atwo phase commit protocol64Transactions
Two-Phase Commit protocol - 4actions by participant:Steps taken byparticipantprocess in 2PC.65write INIT to local log;wait for VOTE REQUEST from coordinator;if timeout {write VOTE ABORT to local log;exit;}if participant votes COMMIT {write VOTE COMMIT to local log;send VOTE COMMIT to coordinator;wait for DECISION from coordinator;if timeout {multicast DECISION REQUEST to other participants;wait until DECISION is received; /* remain blocked */write DECISION to local log;}if DECISION GLOBAL COMMITwrite GLOBAL COMMIT to local log;else if DECISION GLOBAL ABORTwrite GLOBAL ABORT to local log;} else {write VOTE ABORT to local log;send VOTE ABORT to coordinator;}Transactions
Two-Phase Commit protocol - 5a)b)The finite state machine for the coordinator in 2PC.The finite state machine for a participant.If a failure occurs during a ‘blocking’ state (red boxes), there needs to be arecovery mechanism.66Transactions
Two Phase Commit Protocol - 6Recovery‘Wait’ in Coordinator – use a time-out mechanism to detect participantcrashes. Send GLOBAL ABORT‘Init’ in Participant – Can also use a time-out and send VOTE ABORT‘Ready’ in Participant P – abort is not an option (since already voted toCOMMIT and so coordinator might eventually sendGLOBAL COMMIT). Can contact another participant Q and choosean action based on its state.State of QAction by PCOMMITTransition to COMMITABORTTransition to ABORTINITBoth P and Q transition to ABORT(Q sends VOTE ABORT)READYContact more participants. If all participantsare ‘READY’, must wait for coordinator torecoverTransactions67
Two-Phase Commit protocol - 7actions for handling decision requests: /* executed by separate thread */while true {wait until any incoming DECISION REQUEST is received; /* remain blocked */read most recently recorded STATE from the local log;if STATE GLOBAL COMMITsend GLOBAL COMMIT to requesting participant;else if STATE INIT or STATE GLOBAL ABORTsend GLOBAL ABORT to requesting participant;elseskip; /* participant remains blocked */Steps taken for handling incoming decision requests.68Transactions
Three Phase Commit protocol - 1Problem with 2PCIf coordinator crashes, participants cannot reach adecision, stay blocked until coordinator recoversThree Phase Commit3PCThere is no single state from which it is possible tomake a transition directly to either COMMIT orABORT statesThere is no state in which it is not possible to make afinal decision, and from which a transition toCOMMIT can be made69Transactions
Three-Phase Commit protocol - 2a)b)70Finite state machine for the coordinator in 3PCFinite state machine for a participantTransactions
Three Phase Commit Protocol - 3‘Wait’ in Coordinator – same‘Init’ in Participant – same‘PreCommit’ in Coordinator – Some participant has crashed but we know itwanted to commit. GLOBAL COMMIT the application knowing that once theparticipant recovers, it will commit.‘Ready’ or ‘PreCommit’ in Participant P – (i.e. P has voted to COMMIT)State of QAction by PPRECOMMITTransition to PRECOMMIT. If all participantsin PRECOMMIT, can COMMIT the transactionABORTTransition to ABORTINITBoth P (in READY) and Q transition to ABORT(Q sends VOTE ABORT)READYContact more participants. If can contact amajority and they are in ‘Ready’, then ABORTthe transaction.If the participants contacted in ‘PreCommit’ itis safe to COMMIT the transactionNote: if any participantis in state PRECOMMIT,it is impossible for anyother participant to be inany state other thanREADYor PRECOMMIT.Transactions71
Schemes for Concurrency control Locking Server attempts to gain an exclusive ‘lock’ that is about to be used by one of its operations in a transaction. Can use different lock types (read/write for example) Two-phase locking Optimistic concurrency control Time-stamp based concurrency control
devoted to designing concurrency control methods for RTDBS and to evaluating their performance. Most of these algorithms use serializability as correctness criteria and are based on one of the two basic concurrency control mechanisms: Pessimistic Concurrency Control [3, 12] or Optimistic Concurrency Control [2, 4, 5, 6, 11]. However, 2PL
Concurrency control Concurrency control in DBS methods for scheduling the operations of database transactions in a way which guarantees serializability of all transactions ("between system start and shutdown") Primary concurrency control methods – Locking (most important) – Optimistic concurrency control – Time stamps
locking concurrency control unsuitable for nested transaction. 3. Optimistic concurrency control can be dangerous . If a nested transaction is aborted, the number of dependent transactions that need be aborted will be larger, which in turn will cause a even large r number of transactions to abort. That is, the
Core Java Concurrency From its creation, Java has supported key concurrency concepts such as threads and locks. This guide helps Java developers working with multi-threaded programs to understand the core concurrency concepts and how to apply them. Topics covered in this guide include built-in Java
CS390C: Principles of Concurrency and Parallelism Course Overview Introduction to Concurrency and Parallelism Basic Concepts Interaction Models for Concurrent Tasks Shared Memory, Message-Passing, Data Parallel Elements of Concurrency Threads, Co-routines, Events Correctness Data races, linearizability, deadlocks, livelocks, serializability
strate that the validation methods should be adaptively se-lected according to the type of operation in a transaction and the characteristics of its current workload. Optimistic concurrency control (OCC) protocol divides the execution of a transaction into three phases: read, val-idation and write. A transaction validates its reads and
processing processing a keyed transaction processing a transaction swiped transactions 5 6 refunding a transaction voiding a transaction 7 reissuing a transaction 8 recurring transactions 1 of 2: setting up a recurring transaction on a previously used card 2 of 2: setting up a recurring transaction on a new card 9 part five: reporting
His catalogue includes a ballet, orchestral, chamber, piano, vocal and choral compositions. His unrecorded Symphonies are: Nos. 2 for Pipa and Large Orchestra (1981), 7 for Chinese Orchestra "The Great Wall" (2004) and 8 for Organ, hoir and Orchestra "This oundless Land’ (2007). Symphony No. 1 (1979) Wing-Sie Yip/Russian Philharmonic Orchestra ( Symphony No. 3 and Morning Sun) HUGO HRP 795 .
