Integrity Checking for Nested Transactions

Integrity Checking for Nested Transactions Bruno Defude Institut National des Telecommunications, 9, Rue Charles Fourier, 91011 Evry Cedex - France Herve Martin Laboratoire de Genie Informatique, IMAG-Campus, BP 53X 38041 Grenoble Cedex - France

Abstract

In this paper, we present a mechanism to specify and to validate consistency constraints in object oriented databases. Constraints are speci ed using pre and post-conditions associated with an exception handling mechanism. During transaction run-time, we treat exceptions corresponding to errors (in this case, we use immediate exceptions which are processed immediately) or presumption of errors (in this case, we use deferred exceptions which are processed at the end of the transaction), in order to insure validation. To re ne our mechanism, we enlarge it to nested transactions. Deferred exceptions can be processed at each node of the transaction tree. Using a prede ned exception, we propagate an abort of a sub-transaction to its parent transaction. Thus, the parent transaction can choose among dierent policies for processing the sub-transaction abort.

1 Introduction

For the programming point of view, writing applications in an object-oriented databases framework is still a delicate task. The main reasons are the complexity of these systems and the lack of declarative tools dedicated to assist the programmer in his task. Until now, commercial products have essentially concentrated their eorts on sophisticated generating tools for human-computer interactions which are well integrated into the development environment. Moreover, many commercial object-oriented database products oer transaction tool boxes which allow powerful expression of transaction control (nested transactions, long transactions, coupling mode between transaction and versioning mechanism, ). However, these tool boxes are not easy to use and are intended for expert programmers. The main objective of our work is to provide syn-

tactical constructions to express integrity constraints in an object-oriented manner and an execution model to handle eciently integrity constraints. Our execution model is based on exceptions and is tightly coupled with the underlying transaction model which is supposed to be a nested transaction model. We claim that data and operation consistency is an important challenge because a large part of transaction code is dedicated to such controls. We aim to simplify the application programming task by avoiding embedding code to handle integrity constraints in application code. When this code is embedded in application code it becomes hard to maintain, hard to evolve and hard to reuse. Our goal is not to de ne a new object-oriented DBMS or to propose a new database programming language. We just propose to couple our exception mechanism with an existing object-oriented DBMS. The paper is organized as follow. In section 2, we brie y present our language to express integrity constraints. In this case, the main relevance of the approach is the natural way we express constraints in an object-oriented schema. The principles of our execution model are also presented. Section 3 is the generalization of the approach presented in section 2. We focus on the link between the underlying transaction model and the exception mechanism. We also show how the exception approach is well suited for nested transactions. Finally, in the conclusion, after introducing future work and presenting the status of the implementation, we compare our work with related works.

2 Object-oriented integrity constraints In this section, we brie y present our integrity constraints expression and execution model in object databases. The model is precisely described in [2].

The general idea of our integrity model is inspired by programming languages in order to use pre and postconditions for proofs [6]. We adapt the programming language approach to take into account database speci cities such as transactions and persistency. Data integrity is described using the behavior that is described by methods into classes. Each method is associated with a pre and a post-condition. The precondition expresses the right evaluation conditions of a method. The post-condition is used to restrain the set of acceptable nal states of the method. We consider that the method execution is consistent if pre and post-conditions are established. This de nition of consistency is very strong and must be relaxed to take into account two problems. First, some behavior cannot be characterized locally at the end of the method. These kinds of behavior must be considered as suspicious at the local level and then be evaluated globally at the end of the transaction when all the required information is available. According to the context, we make the decision of accepting or refusing the behavior at the global level. Second, as stated above, a consistency mechanism must be exible enough to take into account exceptions to general rules [3]. So, before refusing a behavior, we need to check whether the present case refers to an exceptional case. Exceptional cases must be considered as correct and not inconsistent. To relax our mechanism, an exception mechanism is associated with pre and post-conditions. When a pre (post)-condition is violated an exception is raised. Exception can be handled immediately (in the case of local control) or in a deferred way (at the end of the transaction, in the case of a global control). The exception handler (the body) corresponds to exceptions to general rule that are speci ed using pre(post)-conditions. These exceptions to the general rules take the form of couple condition-action series. Possible actions are either continue (in the case of an exception to the general rule), or abort (a rule without exceptions). To simplify body speci cation, only couples corresponding to an exception to the general rule must be speci ed. The action part (continue) is implicit and is omitted. We consider that if the body is empty or if there is no condition evaluated to true into the body then the rule is violated. If a condition is evaluated to true, then the condition represents an exception to the general rule. Execution of a method m is considered as consistent if the pre-condition and the post-condition of m are satis ed. Execution of a transaction T is consistent if the execution of every method invoked by T is consistent and if the post-condition of T is satis ed (we make the assumption that the pre-condition of a transaction is always satis ed). The post-condition of a transaction

is compound by all deferred exceptions that have been raised during execution of T. Example 1: We now present an example of a very simple student registration. We consider that a set of students have to be registered to a set of modules. The Module-Registration() operation is de ned in the class Module. We want to express the following constraint (in a logical formalism): 8 m 2 Extension(Module), nb-of-registration(m) capacity(m) that is a module can accept a limited number of students. This condition is expressed by a pre-condition (we note pre) in the Registration-Module method. method Registration-Module(stu : Student) in class Module fpre nb-of-inscription(receiver)  capacity(receiver) signal pb-of-capacity(stu)g exception pb-of-capacity (e : Student) of type immediate in class Module body exception pb-of-capacity (e : Student) in class Module freceiver 2 Mandatory(Pro le(e))g The pb-of-capacity exception allows us to accept registration for the student in the case that the module is mandatory for this student (according to his/her pro le). More generally, a student has to choose at least six modules but it is possible that he/she has already gained some modules: 8 e 2 Extension(Student), nb-of-module(e)  6 this constraint is expressed by a post-condition (we note post) in the student-registration method: method student-registration in class Student fpost nb-of-module (receiver) 6 signal Not-enough()g exception Not-enough() of type deferred in class Student body exception Not-enough() in class Student f nb-of-module (receiver) + gain (receiver)  6 g Because the exception type is deferred, the Not-enough exception will be considered at the end of the transaction. It is not possible to process control immediately because all the required information is not available at the method level (it is only at the end of the transaction that we are aware of all chosen modules). Reusability is one of the most important characteristics of the object paradigm. The class is the unit of reusability. Nevertheless to be able to reuse a class, it is necessary to adapt and so to specialize this class in order to face new needs. Our approach is well suited for this requirement because it allows us to adapt integrity speci cation to the new context. Example 2: In the second example we will de ne the Phd-registration method in class Student. Consider that to accept the registration, the student must have