N. Defrancesco et G. Vaglini, CONCURRENT BEHAVIOR - A CONSTRUCT TO SPECIFY THE EXTERNAL BEHAVIOR OFOBJECTS IN OBJECT DATABASES, DISTRIBUTED AND PARALLEL DATABASES, 2(1), 1994, pp. 33-58
Citations number
26
Categorie Soggetti
Computer Sciences, Special Topics","Computer Science Theory & Methods","Computer Science Information Systems
We present a linguistic construct to define concurrency control for th
e objects of an object database. This construct, called concurrent beh
avior, allows to define a concurrency control specification for each o
bject type in the database; in a sense, it can be seen as a type exten
sion. The concurrent behavior is composed by two parts: the first one,
called commutativity specification, is a set of conditional rules, by
which the programmer specifies when two methods do not conflict each
other. The second part, the constraint specification, is a set of guar
ded regular expressions, called constraints, by which the programmer d
efines the allowed sequences of method calls. At each time during an a
ctual execution, a subset of constraints may be active so limiting the
external behavior of the object. A constraint becomes active when its
guard is verified, where a guard is composed of the occurrence of som
e method call m along with the verification of a boolean expression on
the object state and the actual parameters of m. A constraint dies wh
en a string of the language corresponding to the regular expression ha
s been recognized. While the commutativity specification is devoted to
specify the way in which the external behavior of an object is influe
nced by the existence of concurrent transactions in the system, the co
nstraint specification defines the behavior of the object, independent
ly from the transactions. Since the two parts of the concurrent behavi
or are syntactically distinct and, moreover, each of them consists of
a set of independent rules, modularity in specifying the objects is en
hanced, with respect to a unique specification. We outline an implemen
tation of the construct, which is based on a look-ahead policy: at eac
h method execution, we foresee the admissible successive behaviors of
the object, instead of checking the admission of each request at the t
ime it is actually made.