Cloud CM-IPMP Průvodce řešením problémů stáhnout pdf (Strana 195)

entities, proﬁles, Activity Context state, and event queues. The transaction that has successfully acquired the exclusive lock on

a unit of transacted state will not release this lock until the transaction has either committed or rolled back.

Concurrent transactions may deadlock against each other, when more than one lock is held by each transaction and the locks

are acquired in different orders in the concurrent transactions.

D.3.2 Optimistic Concurrency Control

In the optimistic model, each unit of transacted state has a version number and a value. When a transaction ﬁrst accesses a

unit of transacted state, a copy of both the committed version number and value are made, and used for all operations in the

transaction. If the transaction rolls back, the copies are simply discarded. If the transaction attempts to commit, the version of

the committed state is compared against the version of the isolated state. If the version numbers match, the commit is applied

and the committed version number is modiﬁed according to some Resource Manager speciﬁc function. If the version numbers

do not match, the transaction will roll back as committing the transaction would violate the isolation guarantees.

D.3.3 Summary

The optimistic model has the advantages that no locks are acquired, so the overhead of lock acquisition is not incurred during

transaction processing, and deadlock detection algorithms are not required to execute. The pessimistic model has the advantage

that the data used inside the transaction is not necessarily copied, and therefore cannot ‘change underneath’ the transaction.

Whether one approach is better than the other approach depends on the characteristics of the application in terms of concurrent

access. It is also possible that different resource managers exhibit greater performance when using one concurrency control

mechanism over another.

D.4 Processing Components and Commit Protocols

D.4.1 Transaction Processing Components

Transacted Resource

A Transacted Resource allows operations to be performed on it in a manner that maintains the ACID properties of the transacted

programming model. Common examples of transacted resources include Relational Databases, Object Databases, and JMS

message queues when used in transacted mode.

Resource Manager

A Resource Manager manages one or more instances of a Transacted Resource. For example a Relational Database Server may

serve several Relational Databases. A Resource Manager typically supports a one-phase commit, and may or may not support

two-phase commit.

Transaction Manager, Transaction Co-ordinator

A Transaction Manager or Transaction Co-ordinator is responsible for demarcating transaction boundaries in a Transacted

Resource, and may co-ordinate several transacted resources in a single transaction. A Resource Manager may or may not

include a Transaction Manager.

D.4.2 Multiple Resource Managers

There are certain scenarios where it is possible to use multiple Resource Managers in a single transaction. These scenarios use

a two-phase commit protocol between the Transaction Manager and the Resource Manager

A two-phase commit protocol is a contract between the Transaction Manager and a Resource Manager rather than a wire protocol. For example the

two-phase commit protocol is often realised as a local API, a remote API, or a wire protocol carrying the semantics of the two-phase commit protocol.

Open Cloud Rhino 1.4.3 Administration Manual v1.1 186

1 2 ... 190 191 192 193 194 195 196 197 198 199 200 201

Cloud CM-IPMP Průvodce řešením problémů Strana 195