A Framework for Heterogeneous Concurrency Control Policies in Distributed Applications Ant´onio Rito Silva, Jo˜ao Pereira and Jos´e Alves Marques INESC/IST Technical University of Lisbon R. Alves Redol no 9, 1000 Lisboa, PORTUGAL Tel: +351-1-3100287 Fax: +351-1-3145843 E-mail:
[email protected]
This paper appeared in the IEEE Proceedings of tives, such as locking [Eswaran 76] or timestamping the 8th International Workshop on Software Specifica- [Thomas 79]. tion and Design. March 1996. Velen, Germany. Concurrency control policies are built on top of lower level components which implement concurrency control mechanisms, including synchronization Abstract and communication components such as conditions or atomic broadcast. Several concurrency control policies for distributed systems We present an abstract framework that establishes have been proposed both by theorists and practitioners. In this paper we present an abstract framework for concurrency a uniform interface to distributed concurrency control control policies for the serial model. This framework sup- policies for the serial model (serializability policies). ports a wide range of policies and permits the integration of Particular policies are built by derivation of the framedifferent policies within the same application. It is shown work. how the framework is instantiated for several policies: strict The framework also permits the coexistence of two-phase locking, strict timestamping, optimistic and loheterogeneous concurrency control policies within the cal timestamping. The framework defines a uniform intersame application. Policies are constructed by instantiface for distributed concurrency control policies, such that a ating three characteristics: transaction execution order smooth replacement of policies during development is posdefinition time; object accesses consistency check time; sible. and used synchronization primitives. The framework specifies an architecture for a logically distributed application which integrates the design of several heterogeneous concurrency control policies.
1 Introduction Usually concurrency control deals with the isolation property of transactions. Isolation ensures serial execution of transactions in face of concurrency. Recently, it has been raised that some applications need to relax isolation to allow interference, e.g. cooperative work applications [Barghouti 91]. So, in a wider sense, concurrency control should allow a particular model of transaction interference. We call these models concurrency control models.
2 Related Work Domain specific architectures result from a domain analysis [Arango 91] activity which abstracts the domain and defines the structure and behavior holding its reusable part. Several authors have addressed the issue of distributed concurrency control in depth:
Each concurrency control model can be supported by different concurrency control policies. For instance, the serial model, where each transaction sees only the effects of committed transactions, is supported by two kind of policies: pessimistic and optimistic [Kung 81]. Both kinds can use different synchronization primi-
Concurrency control policies can be implemented following two different perspectives [Ozsu 91]: pessimistic, when the application is expected to have high contention, and optimistic, when the level of contention is supposed to be 1
low. Policies are further distinguished by their based on an object-oriented framework. This is a novsynchronization primitives: locking or times- el work since it is independent of a specific platform tamping. and integrates a wide range of concurrency control policies. Weihl defines concurrency control in the context of atomic objects [Weihl 84]. An atomic object encapsulates concurrency control and recovery control. Global serializability is achieved using 3 Abstract Framework local object properties [Weihl 89]. Three local properties are explored: dynamic protocols, in The design of concurrency control policies for the sewhich the serialization order of transactions is rial model is guided by an abstract framework. An determined from the order in which they access object oriented framework is an aggregation of collabthe objects; static protocols, in which the serial- orating classes with a common purpose. It constitutes ization order of transactions is defined at transac- a skeleton which should be fleshed out to build comtion creation time; and hybrid protocols, which plete applications [WB90]. The framework permits define the serialization order when a transaction the design of concrete systems where heterogeneous finishes. All atomic objects accessed by a trans- policies can coexist. action must use the same local atomicity propTo support transactions the usual basic architecerties, otherwise global serializability cannot be achieved [Weihl 89]. ture of transactional systems (transactions, transaction managers and object managers) is adopted as the main Concurrency control is supported by several sysstructure. A structure to represent logic distribution is tems which implement atomic objects and local also supported by the framework. atomicity, for instance Argus [Liskov 88], Avalon [Eppinger 91], Arjuna [Shrivastava 91] and HerWe divide concurrency control policies into three mes/ST [Fazzolare 93]. These systems use nest- parts: order definition, order control and recovery coned transactions and two-phase locking as their trol. Specialization of these parts results in concrete default concurrency control policies. It is pos- systems. sible to use other policies but they must be imOrder definition and order control together conplemented by the programmer without explicit stitute what is usually referred to as serial control. support. Serial control guarantees that transactions execution Guerraoui describes an object-oriented system is serializable and separates execution order definithat abstracts some of the aspects of distributed con- tion from object access control. This allows for obcurrency control policies [Guerraoui 94]. Starting from jects to have their own local concurrency control poliWeihl’s work, he proposes an object-oriented system cies independently of the global serial order as in where objects can possess different local atomicity [Guerraoui 94]. Recovery control guarantees preserproperties if some global serialization protocol exists. vation of a consistent state in spite of transaction failThe global serialization protocol defines a global seri- ures. al order of execution which is defined outside objects. Emphasis is put on order definition and order conGlobal serialization protocols are grouped in three trol. Recovery control functionality is isolated in the classes: static, dynamic and hybrid, as in [Weihl 89]. architecture but particular solutions are not discussed. The object-oriented approach is claimed to be suitable for the development of distributed applications [Blair 90]. Object-oriented analysis and design methods, e.g. [Booch 94, Coleman 94], are becoming widely used in the development of applications. Nevertheless, developing applications for distributed objectoriented systems involves issues that suggest deep changes in current methods [Coleman 94]. Objectoriented frameworks [WB90] can support the structure and behavior resulting from a domain analysis. In particular, Schmidt proposes a framework [Schmidt 95b] which simplifies the development, configuration and reconfiguration of applications.
The notation in this paper follows [Booch 94].
3.1 Structure The framework’s structure is centered on the support of logic distribution, transactions and atomic objects. 3.1.1 Logic distribution
The framework supports introduction of concurrency control into the specification of a distributed applicaWe propose an approach to the development tion. A specification is divided into worlds. Applicaof applications with distributed concurrency control tion objects must belong to one and only one world 2
and objects belonging to different worlds should communicate by explicit message passing. This approach is based on the definition of logically distributed software [Bal 89]. Logically distributed worlds abstract a wide range of distributed applications since they only establish the concept of world, postponing decisions about other characteristics of a distributed system.
distributed set in that world. The distributed set of a transaction in a world is useful for the definition of the distributed commit protocol. For example, the tree of transactions in figure 2 has three distributed sets: ft1,t5,t6g, ft2,t3g and ft4g in worlds W1, W2 and W3 respectively.
Worlds are represented by classes (figure 1) and are responsible for objects registration and system configuration. Worlds are autonomous entities with a predefined interface to other worlds. World configure() registerObj()
1
W1 t1
W2
W2 t2
t3
W3
N
W1 t4
Object
W1
t5
t6
Figure 2: Tree of transactions Figure 1: Logic Distribution
Each world (figure 3) has a transaction manager object responsible for the definition of the transactions’ execution order. Transaction managers are also responsible for the creation, commit, abort and destruction of transactions. The framework defines transaction managers and transaction classes in the context of worlds. Note that the distributed set of a transaction in a world can be derived from existing relationships.
Objects registration within worlds permits to logically distinguish between inter-world communication, when the objects involved in the communication belong to different worlds, and intra-world communication, when the objects belong to the same world. Inter-world communications are also called remote communications and will be relevant in the creation of distributed sub-transactions.
1
Configuration may be dynamic, if worlds can be created or destroyed during the system’s lifetime, or static, otherwise.
World
1
Transaction Manager statOrder() dynOrder() hybOrder()
In order to introduce distributed concurrency control policies in a specification the designer should first use the framework to specify logic distribution.
N Transaction
1 {ordered} parent
1
N sub
nested
Figure 3: Transactions and Transaction Managers.
Concurrency control policies establish different ways of defining transactions execution order [Weihl 89]. Worlds must be capable, via transaction Worlds can have different concurrency control poli- manager, of autonomously define their local transaccies, i.e., the design of concurrency control is done on tions’ execution order. The transaction manager can use a static policy (operation statOrder), a dynama per world. ic policy (operation dynOrder) or an hybrid policy We use transactions to support concurrency con- (operation hybOrder). A problem appears if the sevtrol. A transaction is a transient entity representing eral local orders of execution defined in each world atomic execution of several operations. Transactions are incompatible. Our solution for this problem folensure isolated execution of their operations. lows [Pu 88]: a local transactions’ execution order is defined in each world and a global execution order The framework uses nested and distributed transis constructed using local orders. If the global order actions to handle distribution. Nested transactions is acyclic the transaction commits, otherwise it must [Reed 78] define a tree of transactions allowing conabort. currency among sub-transactions and partial recovery of sub-transactions. 3.1.2
Transactions
The tree of transactions may span several worlds. 3.1.3 Atomic objects The set of transactions of a tree of transactions belonging to a world is part of the distributed structure of that Atomic objects control the transactions’ execution ortree. Each of these sets is called the top transaction’s der and are responsible for recovery from operations of 3
aborted transactions. They encapsulate recovery con- to increment the matrix without updating previously trol policies and cooperate with the transaction man- defined Access classes. ager to support a particular concurrency control policy. In order to achieve atomicity, transactions should act upon atomic objects. 3.2 Behavior As in [Weihl 89], we support both atomic and nonatomic objects. Incomplete transactions have no effects on atomic objects and accesses are serializable. Atomic objects can only be accessed within a transaction. Transactions may access both kinds, atomic and non-atomic objects. Accesses to non-atomic objects are neither serializable nor recoverable. We support nonatomic objects for efficient implementation of temporary and non-shared objects. In this paper we only consider atomic objects.
The framework’s behavior is centered on the cooperation of objects to support concurrency control policies. We describe some relevant cooperations: transaction creation, atomic object access, two-phase commit protocol, object commit and object abort.
3.2.1 Transaction creation For good design we consider transaction creation and transaction start as different events. Transaction creation corresponds to the creation of a new transaction object and its connection to a tree of transactions. Afterwards, transactions can be started synchronously or asynchronously, allowing concurrency between transactions belonging to the same tree.
To allow a higher degree of concurrency, besides the ordinary distinction between read and write operations, atomic objects can use knowledge of operation semantics [GM83]. A matrix of operation compatibility must be defined for each class. Two operations are compatible when they can execute concurrently within the same object and their effects are serializable.
Transactions are created either explicitly or implicitly. Transactions can be explicitly created by programmers either to start a top transaction or to create a local non-distributed sub-transaction. Transactions are created implicitly during inter-world communications to define distribution boundaries in the transaction tree and to allow distributed commit and recovery. A sub-transaction is created in the invoked world.
Atomic objects are implemented from the original Object and Atomic Interface, Recover, Controller and Access objects (figure 4). Class Object defines part of the application semantics ignoring synchronization. Atomic objects are encapsulated by Atomic Interface objects that intercept all accesses to them. The only accesses we considered to objects are invocations. Controller objects are responsible for managing concurrent accesses and Recover objects for recovery. Operations are associated with Access classes denoting the mode of access, e.g. read. In each instant, Controller objects hold the set of current accesses of unfinished transactions, i.e., neither committed nor aborted. Recover objects encapsulate recovery control policies. Recover
Controller
prepare() commit() rollback()
1
preControl() postControl() schedule()
1
Static policies require execution order to be defined when transactions are created. The transaction manager responsible for the new transaction must implement the statOrder operation to set a transaction execution order before the transaction starts. Transaction creation design is presented in the interaction diagram shown in figure 5. A transaction object must know the object and operation where the transaction starts. This are given as arguments of the constructor of Transaction class1. The new transaction, tr, registers itself in the transaction manager of the invoked object, and in the parent transaction if the new transaction is a sub-transaction.
N Access
1 1
1
1
This design is intended to uniformly cover all possible situations of transaction creation: creation of a transaction in the same world (invoker and invoked objects belong to the same world) and distributed creFigure 4: Atomic Object Structure. ation (invoker and invoked objects belong to different worlds). The creation of a transaction in the same The matrix of operation compatibility is split into world covers both top transaction creation and subdefinitions of Access subclasses. Each Access object transaction creation. The only difference is whether knows its compatibility with a set of known Access operation addSubTr is invoked or not. subclasses and delegates to other Access objects if its 1 This is not shown in the figure for the sake of simplicity. class is not a member of this set. Therefore it is possible Atomic Interface
1
Transaction
Object
4
clrObj: Object CREATE TRANSACTION
tr:Transaction
tm:Transaction Manager
:Atomic Interface
clrTr: Transaction FOR ALL ACCESSING TRANSACTIONS ACCESS COMPABILITY
tr=cons(TRANSACTION) tm=getManager()
GET MANAGER
statOrder(tr)
STATIC DEFINE ORDER IF SUB TRANSACTION REGISTER IN PARENT
IF eDELAY
3.2.2
:Recover
compatible() cmpOrder() dynOrder()
abort()
IF eCONTINUE PREPARE TO RECOVER
Figure 5: Transaction creation.
:Transaction Manager
delay()
IF eERROR
addSubTr(tr)
:Access
preControl()
ORDER COMPATIBILITY DYNAMIC DEFINE ORDER
registerTr()
REGISTER TRANSACTION
:Controller
prepare()
Figure 6: Access protocol.
Atomic object access
3.2.3 Two-phase commit protocol
Once created, a transaction can be started and access the first object. Further invocations from this object to Due to distribution and policy heterogeneity we distinother atomic objects are in the context of this transac- guish transaction termination from transaction commit and abort. A transaction terminates when the inition. tial invocation of a top transaction returns. A transacEach access to an atomic object is controlled using tion commits or aborts only after completion of a proan access protocol after which the operation is invoked tocol that ensures the transaction leaves the system on the original object. This protocol is divided in order consistent. Since policy heterogeneity can generate control and recovery control. different execution orders, the protocol needs to determine if the local orders are compatible, i.e., whether Order control for pessimistic policies enforces that they can generate a serial global order. This protocol access to atomic objects be checked, i.e., only compatiis started when a top transaction terminates. ble operations can execute concurrently. Order control determines whether an access should proceed, wait or The framework supports a two-phase commit abort. For optimistic policies accesses to atomic objects protocol. The two-phase commit protocol is used to are not controlled. ensure atomic commitment of distributed transactions [Gray 79]. The framework includes the behavior necAn Access object is created when a transactional essary to generate the serial global order in the twooperation is invoked. It denotes operation semantics phase commit protocol to reduce the number of mesand will be used in the access protocol to check comsages exchanged. patibility among concurrent accesses to objects. Furthermore,Access objects allow programmers to insert Transaction managers play the roles of both conon-trivial semantic knowledge to achieve a greater ordinators and participants in the two-phase comconcurrency degree. mit protocol. Briefly, when asked by the coordinator (transaction manager of the top transaction), particiThe access protocol is represented in figure 6. pant transaction managers reply with their local execuThe operations encapsulated by preControl and tion orders (first-phase) if the transaction can commit prepare support order control and recovery control, locally, or with an abort result otherwise. After the corespectively. Operations compatible and cmpOrder ordinator has received all the replies, if all participants verify if the transaction can access the object and recan commit locally and the local orders generate a seturn: eERROR, when an internal abort is triggered rializable global order, the coordinator sends a commit within the transaction; eDELAY, when the execution message to the participants, otherwise it sends an abort should be delayed; eCONTINUE, when the transacmessage (second-phase). tion can access the atomic object. Dynamic policies order transactions during object accesses (operation The protocol acts upon the worlds where disdynOrder). tributed sets of the top transaction exist. Each transaction manager of these worlds is a participant. Control The access protocol must be executed in mutual flow does not follow the structure of the tree of transexclusion to prevent interference among transactions actions. trying to access the same atomic object simultaneously. For the sake of simplicity, this is not shown in the Optimistic policies require that, during the first interaction diagram. phase of the two-phase protocol, object accesses done by the preparing transaction must be controlled to verify if only compatible operations have been executed concurrently. For pessimistic policies this is not neces5
: Atomic Interface
sary because atomic objects are already in a consistent state.
COMMIT EFFECTS HOUSEKEEPING
During the first phase the local execution orders can be constructed to implement hybrid policies. coord:Transaction Manager FOR ALL part ACCESSED BY tr ASK TO PREPARE HYBRID DEFINE ORDER FOR ALL part ACCESSED BY tr VERIFY COMPATIBILITY IF eDELAY
part:Transaction Manager
ai:Atomic Interface
:Controller
housekeep()
RE-SCHEDULE PENDING TRANSACTIONS
:Controller
:Recover
commit(tr)
schedule()
Figure 8: Atomic object commit.
prepareTr(tr) hybOrder(tr)
4 Concrete Systems
prepare() postControl() delay()
In the previous sections we have defined an abstract framework for the construction of concurrency control BUILD GLOBAL ORDER checkOrder() policies. The concrete policies are built by derivation of this abstract framework, redefining some operations Figure 7: Two-phase commit protocol: first phase. of some abstract classes and possibly defining some new operations. For each concrete policy we will have During the first phase (figure 7), message to create subclasses of classes defined in the framework prepareTr is sent by the coordinator to each par- to implement the needed redefinitions and the new ticipant asking for the transactions’ execution local or- operations. der. Participant Transaction Manager objects deIn table 9 we show which operations should be fine an execution order, used by hybrid policies, invoking hybOrder. Objects accessed by the transaction ex- redefined for each policy. IF eERROR
abort()
ecute a post order control. If operation postControl returns eERROR, object part is notified that the transaction should abort; if it returns eCONTINUE object part is informed that the atomic object complies with the local serial order; if it returns eDELAY, operation delay is executed and the transaction is delayed. This operation, postControl, is implemented only for optimistic policies.
pessimistic preControl()
statOrder() dynOrder() hybOrder()
static
dynamic
hybrid
yes
postControl() schedule()
optimistic
yes yes
yes yes yes yes
Figure 9: Operations Redefinition and Policies. When the participant transaction manager has received all the answers from accessed atomic objects it For pessimistic policies we need to ensure that returns to the coordinator if the transaction can com- transactions accesses to atomic objects happens in a mit locally and, in the affirmative case, which is the serial way. In this case, operation preControl must serial local order of execution. be redefined (figure 6). In optimistic policies verification of serial accesses to atomic objects is done only when a transaction tries to commit. For this policy 3.2.4 Object commit and abort type, operation postControl must be redefined (figure 7). The second phase of the two-phase protocol consists of In our system, serialization order for hybrid polia commit or abort. The transaction’s commit/abort recies is defined only when a transaction tries to comquires that all objects accessed by it execute operation mit, so we need to redefine operation hybOrder (figcommitTr/abortTr to confirm/rollback the object’s ure 7). For static policies, as the serialization order current state. During commit/abort, recovery policies is defined when a transaction is created, we need to must restore the state or discard recovery objects. redefine operation statOrder (figure 5). Dynamic Upon commit/abort delayed transactions may be policies define the serialization order using operation rescheduled for execution. dynOrder during object access in pessimistic policies (figure 6) or during object prepare (included in operaCommit or abort of an atomic object (figure 8) in- tion postControl) in optimistic policies. The latter vokes operation commit on the Recover object, de- case occurs when the Controller object is verifying stroys all Access objects created by the transaction order compatibility (not explicitly shown in figure 7). (behavior associated to operation housekeep) and Any policy using operation delay should also reverifies whether other delayed transactions can now define operation Schedule so that suspended transaccess the object by invoking operation Schedule. actions can be resumed. 6
We allow simultaneous existence of heterogeneous policies within same application. Furthermore, worlds can independently define their own concurrency control policies. Weihl proved that global serializability is achieved if all atomic objects use the same policy[Weihl 89]. Since each world has a single policy we achieve a local order of serialization within each world. As already referred, to obtain a global serial order, the coordinator’s transaction manager constructs a serialization order using the participant’s local orders. The transaction can commit if the generated global order is serializable, otherwise it aborts.
explicit local order the Controller object is able to detect situations of local deadlock2 in which case a eERROR value should be returned. To avoid deadlocks a transaction only waits a certain amount of time to obtain the lock and, if there is a timeout, aborts.
4.1.2 Strict timestamping policy
Strict timestamping is a pessimistic static timestamping policy. Transactions are serialized according to a unique global order usually relating to the top transaction’s creation time. A transaction aborts when it 4.1 Traditional Policies accesses an object that has already been accessed by a transaction with a higher timestamp. This policy was We now present concrete systems for some traditionproposed in [Thomas 79]. al policies. The name of each subclass identifies the concurrency control policy. To support this policy, we defined subclasses of Transaction Manager and Controller. A new class is defined (Generator) which generates unique 4.1.1 Strict two-phase locking policy timestamps. When a transaction is created, operation statOrder (figure 5) is invoked to generate its execution order which is identified by a global timestamp. To support this policy, we defined special- The operation communicates with a central indepenized subclasses of Transaction Manager and dent entity, a Generator object, that knows the global timestamp associated with each transaction family. If Controller. the transaction is a top one, this central entity generates When using this policy, locks are represented by a unique global timestamp for it, otherwise it gets the Access objects, and transactions need to obtain a lock global timestamp associated with the top transaction. on an object to access it. In this policy object accesses are checked by opDuring object accesses operation preControl eration preControl. This operation checks the lo(figure 6) verifies if the required access is compatible cal order and the access mode to decide if an access with accesses currently granted by the object to trans- should be permitted. The transaction is aborted if the actions accessing it. If the required access is compatible object has already been accessed by a transaction with the transaction is allowed to access the object, other- a higher serial order and the corresponding accesses wise it is suspended by invoking operation delay. are incompatible. The transaction is delayed when An atomic object can resume execution of delayed transactions concurrently accessing the object have intransactions when a transaction that has accessed it compatible accesses, otherwise it proceeds. Strict two-phase locking is a pessimistic dynamic locking policy. This policy was proposed in [Eswaran 76].
commits or aborts. Transactions can be resumed according to the order they were suspended by (FIFO) or not, depending on whether the abstract mechanisms being used offer strong fairness or not. This behavior is defined by operation schedule (figure 8). Afterwards, each resumed transaction checks whether it can access the object. If this is not the case, it will be suspended again.
As with the previous policy we also need to redefine operation schedule and it has a similar behavior. A difference is that transactions should be resumed by the order defined by their timestamps, which implies that abstract mechanisms should support a priority scheduling.
4.1.3 An optimistic policy The framework allows two different versions of the two-phase locking policy, depending on whether there is an explicit local order definition or not. The There are several policies usually classified as optifirst orders conflicting transactions using operation mistic. We describe an optimistic hybrid timestamping dynOrder while in the second case transactions are 2 Deadlocks can always occur without being detected due to disimplicitly ordered only when they commit. By using tribution - global deadlock. 7
policy where a local order is assigned to each transac- 4.2.1 Cooperative Worlds tion by timestamping. This policy uses the parallel validation algorithm proposed in [Kung 81]. There are several ways in which worlds can cooperate. One way is the creation of a global order from During the first phase of the two-phase commit protocol operation hybOrder generates a local seri- local serialization orders, but this is not the only way. al order (figure 7). Operation postControl has to Greater degrees of cooperation imply more communication between entities in the system, especially beverify if the transaction can commit locally. It retween Transaction Manager objects. turns eCONTINUE if the transaction’s access is compatible with those of other transactions that have already There are several reasons for the cooperation becommitted3, taking into consideration local order and tween worlds. They can cooperate to improve the peraccess semantics, otherwise it returns eERROR. formance of the global system or to avoid unnecessary 4 Since in this policy transactions are not delayed it aborts , for example. is not necessary to redefine operation schedule.
An example of cooperation is the definition of the local order in the invoked Transaction Manager Due to asynchronous inter-world communication object taking into account the local order already dethis policy can generate unnecessary conflicting local fined in the invoker Transaction Manager object. orders because timestamps are locally generated. In figure 10, the local timestamping policy, presented in section 4.1.4, is adapted to cooperate with 4.1.4 Local Timestamping Policy the caller (remote transaction manager). local: clr:Transaction tm:Transaction This policy differs from the timestamping policy Manager Manager Generator IF NOT TOP-TRANSACTION askOrder() presented in section 4.1.2 because timestamps are ASK ORDER created by a local entity, not by a central entiUPDATE LOCAL ORDER updLocalOrder() IF NOT A SERIAL ORDER ty. A different Generator object is associated abortTr(tr) ABORT with each Transaction Manager object, i.e., a ELSE getLocalTimestamp() GET LOCAL TIMESTAMP Generator object is not a central entity known by ASSOCIATED TO tr UPDATE LOCAL ORDER updLocalOrder() every Transaction Manager object. This local entity knows the local timestamp associated with each transaction family presented in the world. When a Figure 10: Operation statOrder redefinition. transaction family first appears in a world, the local Generator object creates a local timestamp and assoThe local order is enriched with the caller’s local ciates it to the transaction family. Relatively to strict timestamping policy, it is only necessary to modify order. Thus, it is possible to immediately abort the transaction if they are not compatible and not later operation statOrder (see figure 5). when the transaction will try to commit. This policy has the advantage of not depending on a central entity for the management of timestamps. Nevertheless, since local orders do not follow the glob- 4.2.2 Autonomous Policies al order we can have unnecessary aborts due to transactions that do not conflict with others but have assoA policy is autonomous if its integration with other ciated incompatible local orders. policies does not imply their modification. A policy is autonomous if it does not need to be aware of other worlds’ policies.
4.2 Cooperation and Autonomy
The design of the strict timestamping policy can be non-autonomous. In operation statOrder (figure In this section we discuss how worlds can cooperate 11), object Transaction Manager gets the global and what is meant by autonomous policies. There is a timestamp from the top transaction manager. Because tradeoff between autonomy and cooperation, autonotransaction managers can have different policies, opermy improves application extensibility and cooperation ation getGlobalTimestamp must be present in the improves application performance. interface of all Transaction Manager classes, even 3 In reality, to be more precise, these are not transactions that have if they provide different policies.
committed but all transactions that have done the first-phase of the commit protocol and have not yet aborted.
4 In our system we can have transactions that in reality are unrelated, but apparently conflict due to their serialization order.
8
tm:Transaction Manager IF NOT TOP-TRANSACTION GET GLOBAL TIMESTAMP FROM top ELSE GET GLOBAL TIMESTAMP FROM GENERATOR
top:Transaction Manager
global: Generator
autonomy but can become a powerful optimization technique. In this case, policy independence is not achieved.
getGlobalTimestamp() getGlobalTimestamp()
We allow dynamic order definition, e.g. strict two-phase locking policy, or static order definition, e.g. strict timestamping policy, or hybrid order defFigure 11: Operation statOrder redefinition. inition, e.g. optimistic policies. Furthermore, we allow different worlds to have different local serial orders because transaction managers can make decisions The framework we propose supports the definiabout their own order policies: dynamic, static or hytion of both autonomous and non-autonomous polibrid. Our framework can emulate Guerraoui’s system cies. The difference is that an autonomous policy [Guerraoui 94] if we consider our worlds as his objects, uses the framework’s abstract interface while a nonwhich is natural since both solve the same problems. autonomous one needs to use interfaces of particuThe same policy is implemented for all of a world’s lar policies, which becomes a penalty for application objects for performance reasons. maintenance. The framework achieves a structural separation between control and recovery control. Nevertheless, as pointed out in [Weihl 93], serial policies are not in5 Conclusions dependent from recovery policies. This means that a given framework instantiation using a particular seriThis work is part of the definition of a global develop- alizability policy restricts the set of possible recovery ment process of distribution applications centered on policies. This paper does not present any particuseparation of concerns [Silva 95d]. Concerns, relevant lar recovery control policy but they can be found in for the development of distributed applications, are [Silva 95b]. divided into three levels of abstraction: model, policy Several object-oriented design patterns and mechanism. Models describe users expectations about the application or system behavior, e.g. serial [Gamma 95] have been identified in the frameexecution of transactions. Policies define algorithms work [Silva 95b, Silva 95c, Silva 95a]. which support application models, e.g. strict twoAn implementation [Pereira 94] was done in C++ phase locking. Mechanisms offer components which on UNIX using the DCE threads package. The impleare used by policies to implement their algorithms, e.g. mentation allows the construction of centralized prothreads. totypes with logic distribution which can be debugged This approach guarantees two levels of indepen- without interference of communication faults, errors dence: policy independence and mechanism indepen- or delays. Currently another implementation is going dence. Policy independence permits modular replace- on on top of the ACE environment [Schmidt 94]. ment of policies for the same model without interferIn the near future we intend to integrate within ing with application semantics. Mechanism indepenthis framework concurrency control with replication. dence keeps policies independent from specific mechExtending the framework to support non-strict models anisms, such as threads packages or synchronization of concurrency control is the next evolutionary step. primitives. UPDATE LOCAL ORDER
updLocalOrder()
We present a generic abstract framework for the serial model of transactions concurrency control. This framework allows definition of concrete specializations supporting a wide set of concurrency control policies. Moreover, the framework permits several per-world policies running within the same application, being possible to replace a policy without needing to change other worlds’ specifications. Semantic knowledge of objects can be used to allow a greater level of concurrency. Our framework is platformindependent since we use abstract mechanisms as in [Schmidt 95a].
Acknowledgments We would like to thank Pedro Sousa for the fruitful discussions. We also thank David Matos for his careful proofreading.
References [Arango 91]
New policies can be defined using knowledge about other worlds’ policies. This violates policy 9
Guillermo Arango and Ruben Prieto-Diaz, editors. Domain Analysis and Software Systems Modeling. IEEE Computer Society Press, 1991.
[Bal 89]
Henri E. Bal, Jennifer G. Steiner, and Andrew S. Tanenbaum. Programming Languages for Distributed Computing Systems. ACM Computing Surveys, 21(3):261– 322, September 1989.
[Liskov 88]
Barbara Liskov. Distributed Programming in Argus. Communications of the ACM, 31(3):300–312, March 1988.
[Ozsu 91]
M. Tamer Ozsu. Principles of Distributed Database Systems. Prentice Hall, 1991.
[Pereira 94]
Joao Pereira. Enriquecimento com Con˜ trolo de Concorrˆencia de Especificac¸oes Orientadas por Objectos. Tese de mestrado/master thesis, Instituto Superior T´ecnico, Universidade T´ecnica de Lisboa, Lisboa, Portugal, Setembro 1994.
[Barghouti 91]
Naser S. Barghouti and Gail E. Kaiser. Concurrency Control in Advanced Database Applications. ACM Computing Surveys, 23(3):269–317, September 1991.
[Blair 90]
Gordon S. Blair, Javad Malik, John R. Nicol, and Jonathan Walpole. A synthesis of object-oriented and functional ideas in the design of a distributed software engineering environment. Software Engineering Journal, 5(3):193–204, May 1990.
[Pu 88]
Grady Booch. Object-Oriented Analyis and Design with Applications. The Benjamin/Cummings Publishing Company, Inc., 1994.
Calton Pu. Superdatabases for Composition of Heterogeneous Databases. In Proceedings of the 4th Data Engineering Conference, pages 548–555, Los Angeles, USA, February 1988. IEEE.
[Reed 78]
David P. Reed. Naming and synchronization in a decentralized computer system. Technical Report 205, Ph.D. Thesis, M.I.T. Dept. of Elec. Eng. and Comp. Sci, available as M.I.T. Lab. for Comp. Sci. Technical Report 260, Sept 1978.
[Schmidt 94]
Douglas C. Schmidt. The ADAPTIVE Communication Environment: An ObjectOriented Network Programming Toolkit for Developing Communication Software. In 11th and 12th Sun User Group Conferences, San Jose, California and San Francisco,California, December 1993 and June 1994.
[Schmidt 95a]
Douglas C. Schmidt. An OO Encapsulation of Lightweight OS Concurrency Mechanisms in the ACE Toolkit. Technical Report WUCS-95-31, Washington University, St. Louis, 1995.
[Schmidt 95b]
Douglas C. Schmidt and Tatsuya Suda. An Object-Oriented Framework for Dynamically Configuring Extensible Distributed Systems. BCS/IEE Distributed Systems Engineering Journal, 1995.
[Booch 94]
[Coleman 94]
Derek Coleman, Patrick Arnold, Stephanie Bodoff, Chris Dollin, Helena Gilchrist, Fiona Hayes, and Paul Jeremes. ObjectOriented Development: The Fusion Method. Prentice-Hall, 1994.
[Eppinger 91]
Jeffrey L. Eppinger, Lily B. Mummert, and Alfred Z. Spector. Camelot and Avalon: A Distributed Transaction Facility. Morgan Kaufmann, 1991.
[Eswaran 76]
K.P. Eswaran, J.N. Gray, R.A. Lorie, and I.L. Traiger. The Notions of Consistency and Predicate Locks in a Database System. Comunications of the ACM, 19(11):624–633, November 1976.
[Fazzolare 93]
[Gamma 95]
[GM83]
[Gray 79]
Michael Fazzolare, Bernhard G. Humm, and R. David Ranson. Concurrency control for distributed nested transactions in hermes. International Conference for Concurrent and Distributed Systems, 1993. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley, 1995. Hector Garcia-Molina. Using Semantic Knowledge for Transaction Processing in a Distributed Database. ACM Transactions on Database Systems, 8(2):186–213, June 1983. Jim Gray. Notes on Data Base Operating Systems. In R. Bayer, R. M. Graham, and G. Seegmuller, editors, Operating Systems: An Advanced Course, pages 393–481. Springer-Verlag, New-York, 1979.
[Guerraoui 94]
Rachid Guerraoui. Atomic Object Composition. In ECOOP’94, pages 118–138, Bologna, Italy, July 1994.
[Kung 81]
H. Kung and J. Robinson. On optimistic methods for concurrency control. ACM Transactions Database Systems, 6(2):213–226, June 1981.
10
[Shrivastava 91] Santosh K. Shrivastava, Graeme N. Dixon, and Graham D. Parrington. An overview of the arjuna distributed programming system. IEEE Software, January 1991. [Silva 95a]
´ Antonio Rito Silva, Joao Pereira, and Jos´e Alves Marques. Activity Synchronization Pattern, September 1995. INESC Technical Report.
[Silva 95b]
´ Antonio Rito Silva, Joao Pereira, and Jos´e Alves Marques. Object Recovery Pattern, August 1995. INESC Technical Report.
[Silva 95c]
´ Antonio Rito Silva, Joao Pereira, and Pedro Sousa. Local Serialization Pattern, October 1995. Presented at OOPSLA’95 Workshop on Design Patterns for Concurrent, Parallel, and Distributed Object-Oriented Systems.
[Silva 95d]
´ Antonio Rito Silva, Pedro Sousa, and Jos´e Alves Marques. Development of Distributed Applications with Separation of Concerns. In Proceedings of the 1995 Asia-Pacific Software Engineering Conference APSEC’95, pages 168–177, Brisbane, Australia, December 1995. IEEE Computer Society Press.
[Thomas 79]
Robert H. Thomas. A Majority Concensus Approach to Concurrency Control for Multiple Copy Databases. ACM Transactions on Database Systems, 4(24):180–209, June 1979.
[WB90]
Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener. Designing Object-Oriented Software. Prentice-Hall, 1990.
[Weihl 84]
William Weihl. Specification and Implementation of Atomic Data Types. PhD thesis, MIT, 1984.
[Weihl 89]
William Weihl. Local Atomicity Properties: Modular Concurrency Control for Abstract Data Types. ACM Transactions on Programming Languages and Systems, 11(2):249–282, April 1989.
[Weihl 93]
William Weihl. The Impact of Recovery in Concurrency Control. Journal of Computer and System Sciences, 47(1):157–184, August 1993.
11
