Adaptable Transaction Consistency for Mobile Environments Andry Rakotonirainy CRC for Distributed Systems Technology Level 7, Gehrmann Labs The University of Queensland Qld 4072 Australia
[email protected]
Abstract Consistency criteria adopted for the transactional management of shared objects define the degree of allowable interleaving between concurrent transactions. This paper presents an application aware adaptable framework for mobile environments that uses an adaptable Quality of Service specification. The utility of such a specification is illustrated by the use of an adaptable transaction consistency criterion for mobile environments.1
1. Introduction A mobile system has to evolve and be adaptive during its lifetime. This evolution is driven either by new application requirements or the new state of the environment. It requires the interacting objects to be able to change their behaviour statically or dynamically . Such functionality may result in an unstructured, chaotic system where each object could randomly change its behaviour at will. Quality of Service (QoS) specification defines the expected properties and avoid such effects (if the implementation adheres to the specification). QoS specification of a system asserts that guarantees properties S under the assumption that its environment satisfies some property E [1]. Research on QoS focuses on the specification of properties S provided by a set of objects when its environment behaves correctly. Unfortunately, these works [3] do not specify the property that an object can guarantee when the environment fails to provide the property E . This is a severe lack in terms of adaptable computing. Hence, if a given property cannot be met then
Q
Q
1 The work reported in this paper has been funded in part by the Cooperative Research Centre Program through the Department of Industry, Science and Tourism of Australia.
alternative properties must be clearly specified. Due to their inherent limitations, mobile environments are likely to fail and must adapt their behaviour immediately. We outline a new approach to specifying QoS suitable for adaptable environment and we demonstrate its utility in the description of adaptable transactions for mobile environments. Traditional transaction properties (ACID) are too restrictive for applications running in a mobile environment. Strong transactional properties such as serialisability require many message exchanges and synchronization between distributed components involved in a transaction. Due to its limitation, a mobile environment might not have the ability to achieve such synchronization. Thus, there is a need to weaken transactional properties in such a way that a minimal synchronization is needed when the environment does not allow such complete synchronization. Conversely, there is also a need to, eventually, strengthen those properties when the environmental conditions improve [9]. Relative serialisability is an adaptable consistency criterion able to express most consistency criteria known from the literature [4]. It is a flexible consistency criterion that allows to define weaker correctness compared to serialisability. We use it mainly to swap from serialisability to weaker consistency customised by the user when the environmental conditions are poor. The remainder of this paper is organized as follows. Section 2 states assumptions and terminology we use in this paper. Section 3 presents a new way to specify adaptable Quality of Service. Section 4 describes how adaptability is achieved and presents the adaptable transaction consistency called relative serialisability that we use to relax the properties of transactions running in a mobile environment. Section 6 presents how all the concepts we defined fit together in a big picture. The conclusion rounds out the arguments of the paper. Annex 1 formally state the relative serialisability theoty.
2. Assumptions
3.1 Static QoS
This work starts from the assumption that it is not possible to build abstractions or transparent services that completely hide the underlying physical limitation of a mobile infrastructure, if only because those constraints are physical. This section starts with a reminder of terminology that will help the reader [6, 4]. The characteristics of mobile environments are then given.
A QoS specification asserts that the system performs properly if the environment does. It does not assert that the environment performs properly [1]. RM-ODP describes the QoS as relations that comprise the expectations of an object from its environment and the obligation (or guarantee) of QoS to its environment. This separation of concerns is mainly to separate what can be provided by the environment and what can be performed by the object.
2.1 Terminology Adaptation: Corrective actions that remedy or improve mobile computing constraints. Behaviour: A collection of actions with a set of constraints on when they may occur. Properties: Some aspect of the environment or objects that can be identified, observed and quantified. Properties are either a set of behaviours or quality requirements on the collective behaviour of one or more objects. They are also refered as QoS statements.
2.2 Properties of mobile environments A mobile environment, unlike, its stationary counterpart, has dynamic constraints such as changing resources, unavailability of hardware components, bandwidth fluctuations, limited memory storage, dynamic processing time, new environment configurations (a mobile object is migrated and wakes up in a totally different and heterogeneous environment), mobility of the user, cost of the use of the network and network disconnection/re-connection.
2.3 Mobile QoS Management QoS management activities are driven by the QoS statements. QoS statements are expressions of properties of the environment or system policies. This paper does not tackle the QoS management aspect; it assumes that the management of the QoS is best effort. Thus, QoS statements outlined in this paper are related to the adaptable transaction consistency aspect.
3. QoS specification for an open environment This section discusses the need to extend traditional QoS statement specifications to support adaptable mobile computing environments. QoS statements cover the nonfunctional or property aspect of systems such as accuracy, reliability, or consistency. It is set of quality requirements on the collective behaviour of one or more objects.
Proposition 1 Formally, if E represents the property provided by the environment of an object and S the property guaranteed by an object, then the above sentence can be written as a formula
E =) S:
(1)
S is satisfied as long as E is satisfied.
3.2 Dynamic QoS The above equation did not specify any state of the environment which is liable to lead to object failures. Since mobile environments are often reach a failure state , then it is convenient to identify and characterize the set of faulty environments FEi and state the new object properties, denoted FSi , that holds from FEi .
Q
Proposition 2 Assume that FEi identifies each faulty environment. And faulty environments and well behaved environments are all different, that is, E \ i2n FEi ; then,
P
= X (E =) S ) ^ (FEi =) FSi)
(2)
i2n
Equation 2 assumes that a set of faulty FEi environments are known in advance. We cannot have such an assumption to perform adaptability rules in a heterogenous mobile environment, because there are a broad and unknown range of faulty environments. Thus, Equation 2 is not complete because a mobile environment is unpredictable or cannot be known beforehand. Therefore, we choose the following specification to specify QoS. Proposition 3 Assume FSi set of properties guaranteed when the properties of the environment E is not met, denoted :E .
(E =) S ) ^ (:E =)
X FS ) i2n
i
(3)
Equation 3 states that properties S hold as long as E does and properties FSi hold as long as :E holds. This QoS specification reflects the ability of a system to adapt its
Q
guaranted properties S to Si according to the environment E . Equationn 3 is a complete specification. Note that a faulty environment does not necessarily mean an environment with resource scarcities. It can be another environment with a rich set of resources where interacting objects should be adapted to take full advantage of those resources. Failures are object states which diverges from the original behaviour specification and its properties. It is important to note that unlike the S and FSi clauses, the E and FEi are an assumption about the state of the environment of an object, not the constraints placed on it. The set of properties FSi interrupt the property S if :E holds. Concretely, the defined :E ) Si clause is used to define the properties of an interface that trigger exceptions. Exceptions can be expressed as RM-ODP terminations [6] or CORBA-IDL [8] exceptions.
(
=
)
3.3 Transactional consistency expressed with our QoS specification This section gives an example of transactional consistency expressed with the above dynamic QoS specification. Let’s simplify the above notation and express QoS as three clauses:
Require is a set of properties expressing the expectation of an object from its environment. Provide is a set of properties expressing the obligation that an object must provide to its environment. Exception is a set of properties that holds when Require is no longer valid. The classification of the behaviour of an object into three clauses allows us to state clearly what can be guaranteed by an object. We will see later that this approach also simplifies significantly the QoS negotiation process. The following specification is an example that defines the QoS of a concurrency control interface that ensures serialisability and atomicity of transactions if there is disconnection. Otherwise only relative serialisability is guaranteed. The relative serialisability property will be defined in the next section. Example 1: Interface Concurrency control.QoS f Requirefdisconnection rate = 0g Providefserialisability and atomicityg Exceptionfrelative serialisabilityg g
4. Adaptation: Key to mobility We showed how QoS statements capture dynamic properties. An adaptable interface is an interface having at least one set of Require, Provide and Exception clauses. An adaptation rules specification is complete if the union of Require clauses exhibit all possible states of the mobile environement. Concretely, adaptation rules are merely Events, Conditions and Actions (ECA). Events of interest are watched. Those events have propreties described in the Require clause. Actions are triggered when predicates associated with the occurrence of an event hold. The propreties of the actions are described in the Provide clause. If the Require clause doesn’t hold then actions are triggered to guarantee the properties in Exception clause.
4.1. Adaptive Transaction An adaptable transaction is a transaction with adaptable ACID properties. The four properties of transactions are too restrictive for some types of applications such as cooperative, long-lived and mobile applications. Advanced transaction model research defines alternative transaction models that increase transaction response times by relaxing the original properties. Dynamically relaxing one correctness criterion such as serialisability must be associated with the specification of a new correctness criterion as we showed in the Example 1. It is not computationally acceptable to leave the property of the system unspecified. Swapping from a correctness criterion to a weaker or a stronger correctness criterion is difficult to implement. The difficulty arises from the algorithmic aspect of the concurrency control that guarantees the correctness criteria (if, for example, the correctness criteria are implemented by distinct algorithms then it is practically impossible to do the swap). We use a generic correctness criterion that can easily express other well known correctness criteria. Therefore the algorithm that implements the correctness criteria is implicitly generic to handle other correctness criteria.
4.2 Exploiting the semantic of the application A transaction is an activity which leads to a set of object state changes which are consistent with the object and application semantics. The application semantics are also referred to as transaction semantics. To optimize the response time of overall transaction executions, we exploit the transaction semantics that allows access to objects that are not in a consistent state. Non-consistent states are uncommitted states.
The main contributions in the transaction semantics area were made by [5, 7, 2, 4]. In these approaches, a transaction is split up into shorter Atomic Units (Steps) that are executed as individual transactions, between which concurrent transactions can interleave. This approach relaxes the absolute isolation. It also gives different views of atomicity with respect to different transactions. Example 2: Let us consider three transactions
t = o1 ; o2 ; o3 and t = o1 ; o2 and t = o1 where oi denotes an operation. The traditional serialis0
0
0
00
00
ability requirement imposes the condition that t’ sees t as a single (absolute) atomic unit denoted < o1 ; o2 ; o3 > and vice-versa. The set of operations bounded with < and > must occur in isolation with respect to concurrent transactions. However, by using semantic information this requirement can be relaxed. Hence we can specify that t’ can see t as two < o1 ; o2 >< atomic units denoted by Atomicity t; t0 o3 >. This relative atomicity rule allows o01 ; o02 to interrupt t between o2 and o3 . This visibility can be different for another transaction. t00 sees t as three atomic units denoted Atomicity t; t00 < o1 >< o2 >< o3 >. Due to space limitation, we have omitted to define Atomicity t0 ; t and
( )=
( )= Atomicity(t ; t)
( )
00
Example 2 uses the notation of Agrawal et al. [4] which is a generalization of relative atomicity notation described under the designation of the compatibility set defined in [5], and Breakpoint defined in [7, 2]. It differs from other approaches in that it allows the atomic units to be interleaved arbitrarily even if it is forbidden by relative atomicity rules. From the relative atomicity specification of Example 2, t0 o01 ; o02 cannot interleave with t < o1 ; o2 > according to the rule Atomicity t; t0 ) rule. But it is accepted since the resulting execution is conflict equivalent to the class of schedule (history) derived from the Atomicity t; t0 < o1 ; o2 >< o3 > rule; that is, one of the following relative atomic schedules: H1 o01 ; o02 ; o1 ; o2 ; o3 H2 0 0 0 o1 ; o2 ; o1 ; o2 ; o3 H3 o1 ; o2 ; o3 ; o1 ; o02 where H1 and H2 are serial schedules and H2 is a schedule derived from the relative atomicity rule.
:
:
(
;
:
:
( )= ; :
4.3. Relative serialisability Intuitively, the isolation correctness criterion states that all isolation units must be conflict isolated, relative to a specific transaction, according to relative isolation rules. Conflict isolation means that we do not require full isolation of an atomic unit, but we only require conflict isolation of atomic units. We can determine whether a history is correct by testing a conflict graph derived from the history. The notion of equivalence testing is analogous to the absence of cycles
characterization for serialisability theory. [4] defined an efficient graph based tool, called RSG, whose acyclicity is both a necessary and sufficient condition for the correctness of an execution. This class of schedule is called a Relatively Serialisable schedule (RS), see Annexe 1 for more details. The construction of an RSG(H) is described in [4] where the relative serialisability theorem is defined as follows: Theorem A transaction historic H serialisable iff RSG(H) is acyclic.
= (t; !) is relatively
5. The Big Picture This section shows how the adaptable QoS specification, and the adaptable correctness criteria fit together in a framework. A negotiation is necessary before any interaction. The negotiation allows interacting objects to agree on the semantic definition of faulty and non-faulty behaviour, together with the associated expected properties (QoS). As mobile environments are likely to cross required QoS and generate exceptions; the QoS exception clause states weaker properties and triggers actions that maintain such properties. These actions split up (or join) the atomicity of transactions. When a weaker (or stronger) property is needed then Relative Serialisability theory is then used to guarantee the correct execution of transactions.
5.1. QoS adaptable transaction specification 5.1.1 A simple transaction specification Objects issue transactions from mobile or stationary hosts. Example 3 shows a specification where serialisability of a transaction X is guaranteed as long as the disconnection rate in which interacting objects live are rated more than four percent. When exceptions occur then the transaction X can be splitted into < o1 >< o2 ; o3 > relative to transaction Y. Relative serialisability theory is used to guarantee that the atomicity rules won’t be violated. Example 3: Interface X.QoS inherit Transaction f Require f Disconnection rate > g Provide f Atomicity X; Y < o1 ; o2 ; o3 > g Exception f Atomicity X; Y < o1 >< o2 ; o3 g
(
)= ( )=
3%
>g
The above interface inherits from Transaction class which defines basic ACID properties.
5.1.2 Changing dynamically the consistency criteria Consistency constraints can be relaxed or strengthened during an execution. Reducing the number of atomicity views strengthens the consistency criteria. However strengthening consistency constraints might not be possible if the state of accessed data does not already fulfill the new correctness criteria. Partitioning the transaction into Atomicity views relaxes the consistency constraints. Note that a dynamic relaxation of a consistency constraint do not necessary imply that the history of execution will adhere to the new consistency criteria. If an optimistic concurrency control protocol is used then chances are that the new relaxed correctness criteria cannot be guaranteed, thus the swap wouldn’t be allowed or the transaction has to be aborted.
5.2. QoS Architecture The QoS Management architecture is shown in Figure 1. The policy manager is the upper layer of the QoS architecture. It is responsible for handling negotiations of the three QoS clauses between participant objects and managing adaptability rules. The lower level is the monitoring level. It performs functions such as measuring, corrective actions and federation between QoS managers.
(objects) to negotiate QoS requirements, the type of the interaction including allowable re-negotiation and underlying protocols.
The adaptability module manage the high level description of the adaptability rules and associated QoS such as the Example 3 specification. It dynamically configures the interaction. It also maps the application specification into functions that can be handled by the lower level. 5.2.2 QoS Monitoring QoS monitoring is managed by proxies driven by the adaptability module. Those proxies
perform local processing such as statistics resulting from the higher description of the adaptability module such as disconnection >
3%
call the available Services via the Communication infrastructure. The communication infrastructure can be TCP/IP, e-mail, http, etc. perform coordination functions with remote QoS managers through the QoS federation module. For example this module is needed to measure end-to-end bandwidth.
Application
5.2.3 Services
QoS requirement interface (Provide,Require,Exception)
QoS Manager QoS policy manager
Negotiation Native Interface
Adaptability
Monitoring
Action
Measure
QoS Federation
Communication Infrastructure Event Notification Services
QoS Manager
Transaction Concurrency Control Services Services Resource
Figure 1. QoS Management Architecture
Services are CORBA-like services [8]. The event notification service is used by the Measure and Action modules to watch, report and act asynchronously and periodically, the events on the remote QoS manager, the transaction and the concurrency services. Without going into details, the coordination of the services are abstractly discribed in the Adaptability module and the implementation of such coordination is done by the monitoring and the Service levels. The event notification service can triggers the concurrency control or the transaction Exception clause when the environment fails to provide the QoS requirement. Firing an exception will activate some action under certain conditions. They are described as Event-Condition-Actions. If the relative serialisability property holds then on-going and future transactions are split according to the semantic information from the adaptability module. This chopping is described in Atomicity rules as we showed in section 5.1. Such mechanisms will allow transactions to proceed without waiting for concurrent transactions to complete.
5.2.1 QoS Policy Manager Negotiation of QoS between objects is based on the class of their respective environments.
The negotiation module drives negotiation that precedes any object interactions. This allows participants
6. Conclusions In this paper, we have shown a generic adaptable QoS specification, together with its management. We demonstrated the utility of such specification by expressing an
adaptable transactional consistency criterion, called relative serialisability, suitable for mobile environments. Several notions of consistency known from literature can be expressed with relative serialisability. Unlike the extensive works on fault tolerant systems, our proposal does not try to provide a fault tolerant architecture transparent to the application. Our architecture supports a broad range of faults such as communication faults, power failures, unplanned disconnections as soon as they can be detected and appropriate application aware adaptability actions are defined to somehow remediate the exception. We believe that new languages must be able to express our adaptable QoS to support mobile computing as mobile computing will be fact in the future.
[1] M. Abadi and L.Lamport. Composing specifications. DEC Technical report, 66, October 1990. [2] A.Farrag and M.T.Ozsu. Using Semantic Knowledge of Transactions to Increase Concurrency. 1999. [3] B.Noble and al. Agile application-aware adaptation for mobility. Proceedings of the 16th ACM Symposium on Operating System Principles, 16, October 1997. [4] D.Agrawal and J.Bruno. Relative serializability: An approach for relaxing the atomicity of transactions. ACM Symposium on Principles of Database Systems, 1994. [5] H.Garcia-Molina. Using semantic knowledge for transaction processing in a distributed database. ACM Transactions on Database Systems, 8(2), December 1983. [6] ISO. Basic reference for open distributed processing.iso/iec 10746-1 10746-2 10746-3. 1996. http://www.iso.ch:8000/RM-ODP. [7] N.Lynch. Multilevel atomicity - a new correctness criterion for database concurrency control. ACM Transactions on Database Systems, 8(4), December 1983. [8] OMA. OMG: the common object request broker: Architecture and specification. Rev 2, 1995. http://www.omg.org/. [9] O.Theel and M. Raynal. Static and dynamic adaptation of transactional consistency. INRIA-Rennes Technical Report, 2999, October 1996.
AtomicUnit(k,Ti; Tk ) denotes the k th atomic of Ti unit in Atomicity (Ti ; Tk ). This function can return ;. We use two complementary functions called “pushing forward” and “pulling backward” to delimit the boundary of each atomic unit with respect to relative atomicity rules. Let opij belong to AtomicUnit m; Ti ; Tk .
(
)
Two different tasks conflict, denoted Conflict Tij ; Tkl , if they access the same data and the order of the access matters on the transaction result or the state of the accessed object. Definition 4 An execution history is a partial order of operations oij issued by transaction ti denoted H ti ; ! such that:
=(
(
)
! tk0 iff Conflict oki ; ok0 j and oki happened before ok0 j
)
)
PushForward(opij ; Tk ) is a transaction opip where opip is the last transaction of AtomicUnit(m; Ti; Tk ). Example: PushForward(Intro tk CrossReference twf ) = Conclusion tk is a transacPullBackward(opij ; Tk ) tion opiq where opiq is the first transaction of AtomicUnit(m; Ti ; Tk ). Example: PullBackward(Intro tk; CrossReference twf ) = Intro tk
The relative serialisation graph of a schedule H over T, denoted RSG(H) = (V,E) is a directed graph whose vertices V are the set of operations of T and whose arcs E are constructed as follows:
Internal Transaction arc (I-arc): E contains all the internal arcs of the form opij ! opij +1 where opij and opij+1 belong to the same transaction. Dependency arc (D-arc): E contains all the dependency arcs of the form opij ! opkl such that i 6 k and Conflict opij ; opkl .
(
( )
)
=
PushForward arc (F-arc): For each D-arcs opij ! opkl we add PushForward opij ; Tk ! opkl .
(
APPENDIX: Relative isolation
tk
Atomicity (Ti ; Tk ) denotes a set of the ordered sequence of atomic units of Ti relative to Tj . It can be empty.
(
References
7
H is a conflict graph of transactions. The property (or the correctness) of the transaction execution is deduced from the property of H. To define RSG(H) we introduce some notations and concepts:
)
PullBackward arc (B-Arc): For each D-arcs opij ! opkl we add opij ! PullBackward opkl ; Ti 2
(
=(
)
)
Theorem A transaction historic H t; ! is relatively serialisable iff RSG(H) is acyclic. A proof of this definition and an example can be found in [4]. It also contains proof that RS can express serialisability. 2 Note that if a transaction does not belong to any atomic unit then no conflict arcs is drawn; this considerably reduces the number of arcs in RSG(H).
