![](bg2.png)
a collection of subtransactions that compose the
whole atomic execution unit.
A nested transaction is represented as a tree,
called transaction tree [Moss, 1986, Chen and
Gruenwald, 1994, El-Sayed and El-Sharkawi, 2001,
Reddy and Kitsuregawa, 2000]. A nested transaction
offers more decomposable execution units and finer
grained control over concurrency and recovery than
flat transaction. Nested transactions provide intra-
parallelism, (subtransactions running in parallel) as
well as better failure recovery options, i.e., when a
subtransaction fails and aborts, there is a chance to
restart it by its parent instead of restarting the whole
transaction (which is the case of flat transactions).
Even though, the major driving force in using nested
transaction is the need to model long-lived
applications, nested transactions may also be
efficiently used to model short transactions (like in
the context of real-time database applications, with
specific characteristics).
The main performance goal of RTDBSs
scheduling notably for firm and soft transaction is to
minimize the number of transactions that miss their
deadlines. So, a performance metric in assessing the
system performance in RTDBMSs is the
"throughput". Throughput is defined in terms of the
number of transactions that complete successfully,
which is also called the "success ratio". A
transaction is considered to be successfully
completed if it runs completely and commits its
result before its deadline.
When multiple users access a database
simultaneously, their data operations have to be
coordinated in order to prevent incorrect results and
to preserve the shared data consistency. This
activity is called concurrency control [Abbott, 1988,
Pavlova and Nekrestyanov, 1997], which has always
been a major aspect of computing systems. In recent
years, different real-time concurrency control
protocols have been proposed to both flat and nested
transactions. In this paper, we consider the case of
nested transactions model and its application to real-
time transactions.
The remaining of this paper is organized as
follows. In the next Section, we describe a kind of
nested transactions models. In Section 3, we present
some real-time concurrency control protocols for
nested transactions and we introduce our
concurrency control protocol for real-time nested
transactions. The protocol implementation is
described in Section 4 with some simulation results.
Finally, in Section 5, we conclude and give some
future research directions.
2 NESTED TRANSACTION
MODELS
The main types of the various models of nested
transactions are (1) closed nested transaction [Moss,
1986] and (2) open nested transaction [Madria and
Bhargava, 2000]. In the closed nested transaction
model [Moss, 1986, El-Sated and El-Sharkawi,
2001], a subtransaction’s effect cannot be seen
outside its parent’s view. Originally introduced by
Moss [Moss, 1986], a commitment of a
subtransaction is conditional upon the commitments
of its parent, while in the open nested transaction
model [Madria and Bhargava, 2000], the
subtransactions can execute and commit
independently. The model provides non-strict
execution by taking into account the commutative
properties of the semantics of the operations at each
level of data abstraction. A subtransaction is
allowed to release its locks before the higher-level
transaction has committed. The leaf level locks are
released early only if the semantics of the operations
is known. In many applications, the semantics of
transactions cannot be known and hence, it is
difficult to provide non-strict execution. So, in this
paper, we consider a closed nested transaction
model. Nested transaction extends the flat
transaction by allowing a transaction to invoke
atomic transactions as well as atomic operations. In
a nested transaction model, a transaction may
contain any number of subtransactions, which again
may be composed of any number of subtransactions,
conceivably resulting in an arbitrary deep hierarchy
of nested transactions.
The root transaction, which is not enclosed in
any transaction, is called the top-level transaction
(TLT). Transactions having subtransactions are
called parent transactions (PTs), and their
subtransactions are their children. Leaf transactions
(LTs) are those transactions with no child.
The ancestor (resp. descendant) relation is the
reflexive transitive closure of the parent (resp.
child) relation. We will use the term superior (resp.
inferior) for the non-reflexive version of the ancestor
(resp. descendant). The children of one parent are
called siblings. The set of descendants of a
transaction together with their parent/child
relationships is called the transaction’s hierarchy.
The hierarchy of a TLT can be represented by a so-
called transaction tree. The nodes of the tree
represent PTs, and the edges illustrate the
parent/child relationships between the related
transactions. In the transaction tree shown in
Figure.1, T1 represents TLT or root.
– T1 is a root or TLT,
– T2 and T3 are children of T1,
ICEIS 2004 - DATABASES AND INFORMATION SYSTEMS INTEGRATION
234