Wireless Sensor Network, 2010, 2, 254-263
doi:10.4236/wsn.2010.23035 Published Online March 2010 (http://www.scirp.org/journal/wsn)
ACTIVE-A Real Time Commit Protocol
Udai Shanker, Nikhil Agarwal, Shalabh Kumar Tiwari, Praphull Goel, Praveen Srivastava
Department of Computer Science and Engineering, M. M. M Engineering College, Gorakhpur, India
Received November 19, 2009; revised November 30, 2009; accepted December 15, 2009
Abstract
Many existing real time commit protocols try to improve system performance by allowing a committing co-
hort to lend its data to an executing cohort, thus reducing data inaccessibility. They block the borrower from
sending WORKDONE/PREPARED message and restrict them from lending data so that transaction abort
chain is limited to one. Thus, transaction execution time increases. This paper proposes a modified real time
commit protocol for distributed real time database systems (DRTDBS), Allow Commit Dependent and in
Time borrowers for Incredible Value added data lending without extended abort chain (ACTIVE), where
borrower cohorts are categorized as commit and abort dependent. Further, the commit dependent borrowers
can lend data to executing cohorts with still limiting the transaction abort chain to one only and reducing the
data inaccessibility. Also, an incoming executing cohort having borrowing factor greater than one can only
borrow the dirty data items from lender. This minimizes the fruitless borrowing by the cohort. The perform-
ance of ACTIVE is compared with PROMPT, 2SC and SWIFT protocols for both main memory resident and
disk resident databases with and without communication delay. Simulation results show that the proposed
protocol improves the system performance up to 4% as transaction miss percentage.
Keywords: Distributed Real Time Database System, Commit Protocol, Conflict Resolution, Dependency,
Lender, Borrower
1. Introduction
Maintenance of transaction’s ACID semantics are the
well known complexities that real time distributed data-
base have to contend with when operating on the distrib-
uted data. Several important factors contribute to the
difficulty in meeting transaction deadlines in DRTDBS.
Data conflicts are one of the most important factors
amongst the transactions. Two kinds of conflicts between
transactions [1,2] arise. One occurs between executing
transactions, which is resolved by a concurrency control
protocol to ensure distributed transaction serializability;
the other occurs between executing-committing transac-
tions, which is resolved by a commit protocol to ensure
distributed transaction atomicity. Limited work is done
in case of executing-committing conflicts.
Database systems are currently being used as back-
bone to thousands of applications, which have very high
demands for availability and fast real-time responses. A
large part of the workload consists of read, write-blind
and updates transactions against DRTDBS which these
applications generate. Business transactions using these
applications in the absence of real time could lead to
financial devastations and in worst case cause injuries or
deaths. Examples include telecommunication systems,
trading systems, online gaming, sensor networks etc.
Typically, a sensor network consists of a number of sen-
sors (both wired and wireless) which report on the status
of some real-world conditions. The conditions include
sound, motion, temperature, pressure and moisture, ve-
locity etc. The sensors send their data to a central system
that makes decisions based both on current and past in-
puts. To enable the networks to make better decisions,
both the number of sensors and the frequency of updates
should be increased. Thus, sensor networks must be able
to tolerate an increasing load. For applications such as
Chemical Plant Control, Multi Point Fuel Injection Sys-
tem (MPFI), Video Conferencing, Missile Guidance
System etc., data is needed in real-time, and must be ex-
tremely reliable and available as any unavailability or
extra delay could result in heavy loss. Many applications
listed above using DRTDBS require distributed trans-
action to be executed at more than one site. To maintain
consistency, a commit protocol ensures that either all the
effects of the transaction persist or none of them persist.
Failure of site or communication link and loss of mes-
sages do not hamper the transaction processing. Commit

U. Shanker ET AL. 255
protocols must ensure that little overheads are laid upon
transactions during processing. Hence, the need of de-
veloping a new commit protocol for better performance
of DRTDBS arises.
The two phase commit protocol (2PC) referred to as
the Presumed Nothing 2PC protocol (PrN) is the most
commonly used protocol in the study of DDBS [3–5]. It
ensures that sufficient information is force-written on the
stable storage to reach a consistent global decision about
the transaction. A number of 2PC variants [6] commit
protocols have been proposed and can be classified into
following four groups [7].
1) Presumed Abort/Presumed Commit
2) One Phase
3) Group Commit
4) Pre Commit/Optimistic
Presumed commit (PC) and presumed abort (PA) [8]
are based on 2PC. Soparkar et al. [9] have proposed a
protocol that allows individual site to unilaterally commit.
Gupta et al. [10,11] proposed optimistic commit protocol
and its variant. Enhancement has been made in PROMPT
commit protocol [12], which allows executing transac-
tions to borrow data in a controlled manner only from the
healthy transactions in their commit phase. However, it
does not consider the type of dependencies between two
transactions. The impact of buffer space and admission
control is also not studied. In case of sequential transac-
tion execution model, the borrower is blocked for send-
ing the WORKDONE message and the next cohort can
not be activated at other site for its execution. It will be
held up till the lender completes. If its sibling is activated
at another site anyway, the cohort at this new site will
not get the result of previous site because previous cohort
has been blocked from sending the WORKDONE mes-
sage due to being borrower [13]. In shadow PROMPT, a
cohort forks off a replica of the transaction, called a
shadow, without considering the type of dependency
whenever it borrows a data page.
Lam et al. [1] proposed deadline-driven conflict reso-
lution (DDCR) protocol which integrates concurrency
control and transaction commitment protocol for firm
real time transactions. DDCR resolves different transac-
tion conflicts by maintaining three copies of each modi-
fied data item (before, after and further) according to the
dependency relationship between the lock requester and
the lock holder. This not only creates additional work-
load on the systems but also has priority inversion prob-
lem. The serializability of the schedule is ensured by
checking the before set and the after set when a transac-
tion wants to enter the decision phase. The protocol aims
to reduce the impact of a committing transaction on the
executing transaction which depends on it. The conflict
resolution in DDCR is divided into two parts (a) resolv-
ing conflicts at the conflict time; and (b) reversing the
commit dependency when a transaction, which depends
on a committing transaction, wants to enter the decision
phase and its deadline is approaching.
If data conflict occurs between the executing and
committing transactions, system’s performance will be
affected. Pang Chung-leung and Lam K. Y. [2] pro-
posed an enhancement in DDCR called the DDCR with
similarity (DDCR-S) to resolve the executing- commit-
ting conflicts in DRTDBS with mixed requirements of
criticality and consistency in transactions. In DDCR-S,
conflicts involving transactions with looser consistency
requirement and the notion of similarity are adopted so
that a higher degree of concurrency can be achieved and
at the same time the consistency requirements of the
transactions can still be met. The simulation results show
that the use of DDCR-S can significantly improve the
overall system performance as compared with the origi-
nal DDCR approach.
Based on PROMPT and DDCR protocols, B. Qin and
Y. Liu [14] proposed double space commit (2SC) proto-
col. They analyzed and categorized all kind of depend-
encies that may occur due to data access conflicts be-
tween the transactions into two types commit depend-
ency and abort dependency. The 2SC protocol allows a
non-healthy transaction to lend its held data to the trans-
actions in its commit dependency set. When the prepared
transaction aborts, only the transactions in its abort de-
pendency set are aborted and the transactions in its
commit dependency set execute as normal. These two
properties of the 2SC reduce the data inaccessibility and
the priority inversion that is inherent in distributed real-
time commit processing. 2SC protocol uses blind write
model. Extensive simulation experiments have been per-
formed to compare the performance of 2SC with that of
other protocols such as PROMPT and DDCR. The simu-
lation results show that 2SC has the best performance.
Furthermore, it is easy to incorporate it in any commit
protocol.
Ramamritham et al. [15] have given three common
types of constraints for the execution history of concur-
rent transactions. The paper [16] extends the constraints
and gives a fourth type of constraint. The weak commit
dependency and abort dependency between transactions,
because of data access conflicts, are analyzed. Based on
the analysis, an optimistic commit protocol Two-Level
Commit (2LC) is proposed, which is specially designed
for the distributed real time domain. It allows transac-
tions to optimistically access the locked data in a con-
trolled manner, which reduces the data inaccessibility
and priority inversion inherent and undesirable in
DRTDBS. Furthermore, if the prepared transaction is
aborted, the transactions in its weak commit dependency
set will execute as normal according to 2LC. Extensive
simulation experiments have been performed to compare
the performance of 2LC with that of the base protocols
PROMPT and DDCR. The simulation results show that
2LC is effective in reducing the number of missed trans-
action deadlines. Furthermore, it is easy to be incorpo-
rated with the existing concurrency control protocols.

U. Shanker ET AL. 256
Udai Shanker et al. [17] proposed SWIFT protocol. In
SWIFT, the execution phase of a cohort is divided into
two parts, locking phase and processing phase and then,
in place of WORKDONE message, WORKSTARTED
message is sent just before the start of processing phase
of the cohort. Further, the borrower is allowed to send
WORKSTARTED message, if it is only commit de-
pendent on other cohorts instead of being blocked as
opposed to PROMPT. This reduces the time needed for
commit processing and is free from cascaded aborts.
However, SWIFT commit protocol is beneficial only if
the database is main memory resident. Based on the
SWIFT protocol, Dependency Sensitive Shadow SWIFT
(DSS-SWIFT) protocol [18] was proposed, where the
cohort forks off a replica of itself called a shadow,
whenever it borrows dirty value of a data item, and if, the
created dependency is abort type as compared to creating
shadow in all cases of dependency in Shadow PROMPT.
Also the health factor of cohort is used for permitting to
use dirty value of lender rather than health factor of
transaction as whole.
Here, our modified work proposes a commit protocol
ACTIVE, which allows lender to lend data to healthy
borrowers. Also, commit dependent cohorts are further
allowed to lend data. This protocol is beneficial both for
main memory and disk resident databases.
The remainder of this paper is organized as follows.
Section 2 introduces the distributed real time database
system model. Section 3 discusses the type of dependen-
cies created between conflicting cohorts. Section 4 states
the condition for fruitful borrowing. Section 5 presents
ACTIVE commit protocol and its pseudo code. Section 6
discusses the simulation results and Section 7 gives an
outline for future research directions. Finally, Section 8
concludes the paper.
2. Distributed Real Time Database System
Model
The common model for DRTDBS is given below in Fig-
ure 1. The structure of our simulation model including
the description of its various components such as system
model, database model, network model, cohort execution
model, locking mechanism and the model assumptions is
given below [17,18]. At each site, two types of transac-
tions are generated: global transactions and local transac-
tions. Each global transaction consists of m cohorts,
where m is less than or equal to the number of database
sites Nsite. We use the same model for local and global
transactions. Each local transaction has a coordinator and
a single cohort both executing at the same site. Each
transaction consists of Noper number of database opera-
tions. Each operation requires locking of data items and
then processing.
Figure 1. Distributed real-time database system model.
2.1. System Model
Each site consists of a transaction generator, a transac-
tion manager, a concurrency controller, a CPU, a ready
queue, a local database, a communication interface, a
sink and a wait queue. The transaction generator is re-
sponsible for creating the transactions independent to the
other sites using Poisson distribution with the given in-
ter-arrival time. The transaction manager generates co-
horts on remote site on behalf of the coordinator. Before
a cohort performs any operation on a data item, it has to
go through the concurrency controller to obtain a lock on
that data item. If the request is denied, the cohort is
placed in the wait queue. The waiting cohort is awakened
when the requested lock is released and all other locks
are available. After getting all locks, the cohort accesses
the memory and performs computation on the data items.
Finally, the cohort commits/aborts and releases all the
locks that it is holding. The sink component of the model
is responsible for gathering the statistics for the commit-
ted or terminated transactions.
2.2. Database Model
The database is modeled as a collection of data items that
are uniformly distributed across all the sites. Transac-
tions make requests for the data items and concurrency
control is implemented at the data item level. No replica-
tion of data items at various sites is considered here.

U. Shanker ET AL. 257
2.3. Network Model
A communication network interconnects the sites. There
is no global shared memory in the system. All sites
communicate via messages exchange over the commu-
nication network. The network manager models the be-
havior of the communications network.
2.4. Cohort Execution Model
In our work, we have considered the parallel execution
of cohorts. The coordinator of the transaction spawns all
cohorts together by sending messages to remote sites to
activate them, lists all operations to be executed at that
site and then cohorts may start execution at the same
time in parallel. The assumption here is that a cohort
does not have to read from its sibling and operations
performed by one cohort during its execution are inde-
pendent of the results of the operations performed by
other cohorts at some other sites. In other words, the sib-
ling cohorts do not require any information from each
other to share.
2.5. Locking Mechanism
The main technique used to control concurrent execution
of transactions is based on the concept of locking data
items. A lock is a variable associated with a data item
that describes the status of the item with respect to possi-
ble operations that can be applied to it. Generally there is
one lock for each data item in the database. Locks are
means for synchronizing the access of concurrent trans-
actions to the database items. A transaction is said to
follow the two phase locking protocol if all locking op-
erations precede the first unlock operation in the transac-
tion. There is a number of variations of the two phase
locking (2PL) such as static two phase locking (S2PL)
and dynamic two phase locking (D2PL). The static 2PL
(S2PL) requires a transaction to lock all needed data
items before the transaction begins execution, by prede-
claring it’s read-set and write-set. If any of the prede-
clared data item can not be locked, the transaction does
not lock any items; instead, it waits until all data items
are available for locking.
2.6. Model Assumptions
We assume that the transactions are firm real time tran-
sactions. The model assumptions are listed below.
1) Processing of a transaction requires the use of CPU
and data items located at local or remote site.
2) Arrival of the transactions at a site is independent of
the arrivals at other sites and uses Poisson distribution.
3) Each transaction pre-declares its read-set (set of
data items that the transaction will only read) and up-
date-set (set of data items that the transaction will up-
date).
4) The cohorts are executed in parallel.
5) A lending transaction cannot lend the same data
item in read/update mode to more than one cohort to
avoid cascaded abort.
6) The communication delay considered is either 0ms
or 100ms to study the impact of the network delay on the
system.
7) A distributed real time transaction is said to commit,
if the coordinator has reached to commit decision before
the expiry of the deadline at its site. This definition ap-
plies irrespective of whether cohorts have also received
and recorded the commit decision by the deadlines [19].
8) Each cohort makes read and update accesses.
9) S2PL-HP is used for locking the data items.
10) Studies have been made for both main memory
resident and disk resident database.
11) In case of disk resident database, buffer space is
sufficiently large to allow the retention of data updates
until commit time.
12) The updating of data items is made in transaction
own memory rather than in place updating
3. Types of Dependencies
Sharing of data items in conflicting modes creates de-
pendencies among conflicting transactions and constr-
aints their commit order. We assume that a cohort requ-
ests an update lock if it wants to update a data item x.
The prepared cohorts called as lenders lend uncommitted
data to concurrently executing transactions known as bo-
rrower. Here, the borrower is further divided into two
categories.
1) Commit Dependent Borrower
2) Abort Dependent Borrower
Therefore, modified definitions of dependencies used
in this paper are given below:
Commit dependency (CD). If a transaction T2 updates
a data items read by another transaction T1, a commit
dependency is created from T2 to T1. Here, T2 is called as
commit dependent borrower and is not allowed to com-
mit until T1 commits.
Abort dependency (AD). If T2 reads/updates an un-
committed data item updated by T1, an abort dependency
is created from T2 to T1. Here, T2 is called as abort de-
pendent borrower. T2 aborts, if T1 aborts and T2 is not
allowed to commit before T1.
Each transaction/cohort Ti, that lends its data while in
prepared state to an executing transaction/cohort Tj,
maintains two sets.
1) Commit Dependency Set CDS (Ti): set of commit
dependent borrower Tj, that are borrowed dirty data from
lender Ti.
2) Abort Dependency Set ADS (Ti): the set of abort

U. Shanker ET AL. 258
dependent borrower Tj that are borrowed dirty data from
lender Ti.
These dependencies are required to maintain the ACID
properties of the transaction. Each lender is associated
with a health factor defined as follows:
HF (health factor) = TimeLeft/MinTime
where TimeLeft is the time left until the transaction’s
deadline, and MinTime is the minimum time required for
commit processing. The health factor is computed at the
time when the coordinator is ready to send the YES-
VOTE messages. MinHF is the threshold that allows the
data held by committing transaction to be accessed. The
variable MinHF is the key factor to influence the per-
formance of the protocol. In our experiments, we have
taken MinHF as 1.2, the value of MinHF used in
PROMPT [12].
4. Condition for Fruitful Borrowing
If the deadline of an executing cohort is lesser than a
committing cohort’s commit time, then borrowing of
locked data item is useless. Therefore, for fruitful bor-
rowing, an incoming executing cohort having borrowing
factor (BF) greater than a threshold value must be per-
mitted to borrow the dirty data items from lender. The
borrowing factor can be computed as given below.
Let us consider that transaction/cohort Ti that lends its
data items while in prepared state to an executing trans-
action/cohort Tj, Here, Ti’s voting phase is over and has
entered in decision phase. The commit time (Ci) of Ti is
the mean time required for the decision phase. It includes
the time for sending the final commit message to the
participating cohorts, the time for writing the final deci-
sion into stable storage, the time for permanently updat-
ing the data items for write operations and the time
needed for releasing the locks [1]. The minimum transac-
tion response time (Rj) of Tj can be calculated as given
below [17].
The deadline of a transaction is controlled by the run-
time estimate of a transaction and the parameter slack
factor, which is the mean of an exponential distribution
of slack time. We allocate deadlines to arriving transact-
tions using the method given below. The deadlines of
transactions (both global and local) are calculated based
on their expected execution times [1,17].
The deadline (Dj) of transaction (Tj) is defined as:
Dj = Aj + SF∗Rj
where, Aj is the arrival time of transaction (Tj) at a site;
SF is the slack factor; Rj is the minimum transaction re-
sponse time. As cohorts are executing in parallel, the Rj
can be calculated as: Rj = Rp + Rc
where, Rp, the total processing time during execution
phase and commitment phase, and Rc, the communica-
tion delay during execution phase and commitment phase
are given as below. For global transaction
Rp = max. ((2Tlock + Tprocess)Noper local,(2Tlock + Tprocess)Noper
remote)
Rc = NcommTcom
For local transaction
Rp = (2Tlock + Tprocess)Noper local
Rc = 0
Where, Tlock is the time required to lock/unlock a data
item; Tprocess is the time to process a data item (assuming
read operation takes same amount of time as write opera-
tion); Ncomm is no. of messages; Tcom is communication
delay i.e. the constant time estimated for a message go-
ing from one site to another; Noper local is the number of
local operations; Noper remote is maximum number of re-
mote operations taken over by all cohorts. If T2 is abort
dependent on T1.
The BF can be the ratio of (SF*Rj-Tcom)/Ci. For Fruit-
ful Borrowing.
(SF*Rj-Tcom)/Ci>1
5. ACTIVE Commit Protocol
5.1. Type of Dependency in Different Cases of
Data Conflicts
Let T1 be a transaction/cohort with identifier id1 and
holding a lock on data item x, and let T2 be another
transaction/cohort with id2 requesting the same data item
x, two situation may result depending on the status of T1.
Situation 1: T1 is a prepared cohort called as lender,
lending uncommitted data. When data conflicts occur,
there are three possible cases.
Case 1: Read-update conflict.
If T2 requests an update-lock and it’s BF > 1 while T1
is holding a read-lock a commit dependency is defined
from T2 to T1. First, the transaction id of T2 is added to
the CDS (T1). Then T2 acquires the update-lock
Case2: Update-Update conflict.
If T2 requests an update-lock and it’s BF > 1 while T1
is holding an update-lock and HF(T1) ≥ MinHF an abort
dependency is defined from T2 to T1. The transaction id
of T2 is added to ADS (T1), and T2 acquires the up-
date-lock; otherwise, T2 is blocked.
Case 3: Update-Read conflict.
If T2 requests a read-lock and it’s BF > 1 while T1 is
holding an update-lock and HF(T1) ≥ MinHF, an abort
dependency is defined from T2 to T1. The transaction id
of T2 is added to ADS (T1), and T2 acquires the read-lock;
otherwise, T2 is blocked.
Situation 2: T2 is commit dependent borrower going to
become a lender simultaneously by lending its uncom-
mitted data to an incoming transaction/cohort T3. When

U. Shanker ET AL. 259
data conflicts occur, there are two possible cases of con-
flict.
Case 1: Update-Update conflict.
If T3 requests an update-lock and it’s BF > 1 while T2
is holding an update-lock and HF(T2) ≥ MinHF an abort
dependency is defined from T3 to T2. The transaction id
of T3 is added to ADS (T2), and T3 acquires the up-
date-lock; otherwise, T3 is blocked.
Case 2: Update-Read conflict.
If T3 requests a read-lock and it’s BF > 1 while T2 is
holding an update-lock and HF(T2) ≥ MinHF an abort
dependency is defined from T3 to T2. The transaction id
of T3 is added to ADS (T2), and T3 acquires the read-lock;
otherwise, T3 is blocked.
In our Protocol, locks on data item are granted to those
borrowers whose BF > 1. On the basis of the data con-
flicts discussed above, the access of data items in con-
flicting mode are processed by lock manager as follows.
If (T1 is an independent lender)
{ If ((T2 (BF > 1) CD T1)
{ CDS (T1) = CDS (T1) ∪ {T2};
T
2 is granted Update lock.
}
else if ((T2(BF > 1) AD T1) AND (HF(T1) ≥ MinHF))
{ ADS (T1) = ADS (T1) ∪ {T2};
T
2 is granted the requested lock (read or
Update).
}
else T2 will be blocked;
}
else if(T1 is commit dependent borrower)
{ If ((T2 (BF > 1) AD T1) AND (HF (T1) ≥
MinHF))
{ ADS (T1) = ADS (T1) ∪{T2};
T
2 is granted the requested lock (read
or Update)
}
else T2 will be blocked; }
else T1 is not allowed to lend data
5.2. Mechanics of Interaction between Lender
and Borrower Cohorts
Let us consider three transactions T1, T2 and T3. T2 has
borrowed the data locked by T1 being an independent
lender. If T2 is commit dependent borrower and has be-
come a lender simultaneously by lending uncommitted
data to an incoming transaction/cohort T3, the following
three scenarios are possible:
Scenario 1: T1 receives decision before T2 is going to
start pro ce ssing ph a se after get ting all locks.
T1 is an independent lender
If the global decision is to commit, T1 commits.
1) All cohorts in ADS (T1) and CDS (T1) will execute
as usual and the sets ADS (T1) and CDS (T1) are deleted.
2) If the global decision is to abort, T1 aborts. The co-
horts in the dependency sets of T1 will execute as fol-
lows:
All cohorts in ADS (T1) will be aborted;
All cohorts in CDS (T1) will execute as usual;
Sets ADS (T1) and CDS (T1) are deleted.
If, there is another commit dependent cohort T2 on T1
that has lent its dirty data to another cohort T3, process-
ing will be done as follows.
If T1 aborts or commits, there are two possibilities
with T2.
1) It has either received the Yes-Vote message from its
coordinator, or
2) It is still in wait state for the same.
In case of possibility 1, T2’s Yes-Response Message
will be send to its coordinator. Type of Dependency be-
tween T2 and T3 will be governed by either Situation 1
Case 2 or Situation 1 Case 3 already discussed earlier
depending on whether T3 is update or read. In case of
possibility 2, T3 can not commit until T2 terminates (i.e.
commits or aborts) [21].
Scenario 2: T2 is going to start processing phase after
getting all locks before T1 receives global decision.
If T1 is independent lender, T2 is allowed to send a
WORKSTARTED message to its coordinator, if it is
commit dependent only; otherwise it is blocked from
sending the WORKSTARTED message. It has to wait
until
1) Alternative 1: either T1 receives its global decisions,
or.
2) Alternative 2: its own deadline expires, whichever,
occurs earlier.
In Alternative 1, the system will execute as in the Sce-
nario 1. In Alternative 2, T2 will be killed and will be
removed from the dependency set of T1.
If, there is another cohort T3 has borrowed dirty data
from commit dependent borrower T2, T3 can not commit
until T2 terminates (i.e. commits or aborts).
Scenario 3: T2 aborts befor e T1 receives decision
In this situation, T2’s and T3’s updates are undone and
T2 will be removed from the dependency set of T1. T2 and
T3 will be killed and removed from the system.
5.3. Algorithm
On the basis of above discussions, the complete pseudo
code of the protocol is given below. if (T1 (an inde-
pendent lender) receives global decision before, T2 is
going to start processing phase after getting all locks)
{
ONE: if (T1’s global decision is to commit)
{
T1 enters in the decision phase;

U. Shanker ET AL. 260
All cohorts in ADS (T1) and CDS (T1) will execute as
usual;
Delete set of ADS (T1) and CDS (T1);
}
else //T1’s global decision is to abort
{
T1 aborts;
The cohorts in CDS (T1) will execute as usual;
Transaction in ADS (T1) will be aborted;
Delete sets of ADS (T1) and CDS (T1);
}
if (T2 commit dependent on T1 has lent its dirty data to
another cohort T3)
{
if (T2 has received the Yes-Vote message from its coor-
dinator) // T1 has aborted or committed
{
T2 send its Yes-Response Message its coordinator
T2 & T3 execute as two normal cohorts with T3 dependent
on T1
}
else // T2 is still waiting for Yes-Vote message
{
T3 can not commit until T2 terminates
}
}
}
else if (T2 is going to start processing phase after getting
all locks before, T1(an independent lender) receives
global decision)
{
check type of dependencies;
if (T2’s dependency is commit only)
{
T2 sends WORKSTARTED message;
}
else
{
T2 is blocked for sending WORKSTARTED message;
while (! (T1 receive global decision OR T2 misses dead-
line))
{
if (T2 misses deadline)
{
Undo computation of T2;
Abort T2;
Delete T2 from CDS (T1) & ADS (T1);
}
else GoTo ONE;
}
}
if (T3 has borrowed dirty data item from commit de-
pendent borrower T2)
T3 cannot commit until T2 terminates
}
else //T2 is aborted by higher transaction before,
// T1 receives decision
{
Undo computation of T2 & T3;
Abort T2 & T3;
Delete T2 from CDS (T1) & ADS (T1);
}
5.4. Main Contributions
1) Borrower cohorts are categorized as commit or abort
dependent.
2) Commit dependent borrowers are allowed to further
lend data, thereby reducing the data inaccessibility. The
length of cascaded abort chain is same as in the case of
PROMPT.
3) Borrowing factor is computed for each borrower, so
that lock on requested dirty data items can be granted to
borrowers in fruitful way only.
To maintain consistency of database, cohort sends the
YES-VOTE in response to its coordinator’s VOTE-REQ
message only when its dependencies are removed and it
has finished its processing.
6. Performance Measures and Evaluation
The default values of different parameters for simulation
experiments are same as in [17]. The concurrency control
scheme used is static two phase locking with higher pri-
ority. Miss Percentage (MP) is the primary performance
measure used in the experiments and is defined as the
percentage of input transactions that the system is unable
to complete on or before their deadlines [19].
Since there were no practical benchmark programs
available in the market or with research communities to
evaluate the performance of protocols and algorithms, an
event driven based simulator was written in C language.
In our simulation, a small database (200 data items) is
used to create high data contention environment. For
each set of experiment, the final results are calculated as
an average of 10 independents runs. In each run, 100000
transactions are initiated.
6.1. Simulation Results
Simulation was done for both the main memory resident
and the disk resident databases at communication delay
of 0ms and 100ms. We compared ACTIVE with
PROMPT, 2SC and SWIFT in this experiment. Figure 2
to Figure 6 show the Miss Percent behavior under nor-
mal and heavy load conditions with/without communica-
tion delay. Figure 2 and Figure 3 deal with main mem-
ory based database system while rest of the figures deal
with disk resident database system. In these graphs, we

U. Shanker ET AL. 261
first observe that there is a noticeable difference between
the performances of the various commit protocols throu-
ghout loading range. This is due to careful lending of
data to a borrower. Here, commit dependent borrowers
has also lent data to executing cohort reducing the data
inaccessibility. At the same time, the transaction abort
chain restricts to one only. Also, an incoming executing
cohort having borrowing factor greater than one has been
permitted only to borrow the dirty data items from lender.
Thus, the work done by the borrowing cohort is never
wasted because of better borrowing choice. This mini-
mizes the fruitless borrowing by the cohort. In general
the number of transaction being committed are more than
number of aborted transactions in real life situations. In
this way, we can increase some more parallelism in the
distributed system. The ACTIVE commit protocol pro-
vides a performance that is significantly better than other
commit protocols.
Main Memory Resident Database
Transaction Arrival Rate (no. per second)
10 20 30 40 50
Miss %
0
20
40
60
80
PROMPT
2SC
SWIFT
ACTIVE
Figure 2. Miss % with (RC + DC) at communication delay
0ms normal and heavy load.
Transaction Arrival Rate (no. per second)
246810 12 14
Miss %
0
20
40
60
80
100
PROMPT
2SC
SWIFT
ACTIVE
Figure 3. Miss % with (RC + DC) at communication delay
100ms normal and heavy load.
Disk Resident Database System
Transaction Arrival Rate (no. per second)
3.0 3.5 4.0 4.5 5.0 5.5 6.0
Miss %
0
5
10
15
20
25
PROMPT
2SC
SWIFT
ACTIVE
Figure 4. Miss % with (RC + DC) at communication delay
0ms normal load.
Transaction Arrival Rate (no. per second)
6810 12 14
Miss %
0
20
40
60
80
100
PROMPT
2SC
SWIFT
ACTIVE
Figure 5. Miss % with (RC + DC) at communication delay
0ms heavy load.
Transaction Arrival Rate (no. per second)
2 4 6 8101214
Miss %
0
20
40
60
80
100
PROMPT
2SC
SWIFT
ACTIVE
Figure 6. Miss % with (RC + DC) at communication delay
100ms normal and heavy load.
7. Future Research Directions
Following are some suggestions to extend this work
[13,20].
1) Despite much research in the area of wireless sensor
networks in recent years, the programming of sensor
Mi
ss
(%)
Miss
(
%
)
Miss (%)
Miss
(
%
)
Miss (%)

U. Shanker ET AL. 262
nodes is still time-consuming and tedious. A new para-
digm which seems to be qualified to simplify the pro-
gramming of sensor networks is the Service Oriented
Architecture. The composition of simple services to
more complex ones can be a convenient way to design
applications. To enable the sophisticated techniques
known from service oriented architectures like replica-
tion and migration of services, a transaction model for
sensor networks is required. The paper [22] studied the
applicability of the standard commit protocols Two
Phase Commit (2PC) and Transaction Commit on
Timeout and show in experiments with real sensor nodes
that 2PC can enable consistent service migration in
wireless sensor networks. This study can further be ex-
tended with this protocol.
2) Our performance studies are based on the assump-
tion that there is no replication. Hence, a study of relative
performance of the topic discussed here deserves a fur-
ther look under assumption of replicated sensor data-
bases.
3) The work can be extended for Mobile DRTDBS,
pear-to-pear database systems, grid database systems etc.
where memory space, power and communication band-
width are bottleneck. There is a need to design various
protocols for different purposes that may suit to the spe-
cific need of hand held devices.
4) Biomedical Informatics is quickly evolving into a
research field that encompasses the use of all kinds of
biomedical information, from genetic and proteomic data
to image data associated with particular patients in clini-
cal settings. Biomedical Informatics comprises the fields
of Bioinformatics (e.g., genomics and proteomics) and
Medical Informatics (e.g., medical image analysis), and
deals with issues related to the access to information in
medicine, the analysis of genomics data, security, inter-
operability and integration of data-intensive biomedical
applications. Main issues in this field is provision of
large computing power such that researchers have access
to high performance distributed computational resources
for computationally demanding data analysis, e.g., me-
dical image processing and simulation of medical treat-
ment or surgery and large storage capacity and distrib-
uted databases for efficient retrieval, annotation and ar-
chiving of biomedical data. What is missing today is full
integration of methods and technologies to enhance all
phases of biomedical informatics and health care, in-
cluding research, diagnosis, prognosis, etc. and dissemi-
nation of such methods in the clinical practice, whenever
they are developed, deployed and maintained. Hence it is
another topic of research interest.
8. Conclusions
This paper proposes a new commit protocol ACTIVE for
DRTDBS, where the commit dependent borrower is al-
lowed to lend its data to an incoming cohort. It reduces
the data inaccessibility by allowing the commit depend-
ent borrowers to further act as lenders. Also, to increase
the benefit of borrowing, an incoming cohort having bor-
rowing factor greater than one can borrow the dirty data
items from a lender. This reduces the fruitless borrowing.
To ensure non-violation of ACID properties, checking of
the removal of cohort’s dependency is required before
sending the Yes-Vote message. The performance of AC-
TIVE is compared with other protocols for both main
memory resident and disk resident databases with and
without communication delay. Simulation results show
that the proposed protocol improves the system per-
formance.
As future work, it is desirable to study the perform-
ance of the proposed protocol in real environment.
9. References
[1] Y. Lam, C-L. Pang, S. H. Son, and J. Cao, “Resolving
executing-committing conflicts in distributed real-time
database systems,” Computer Journal, Vol. 42, No. 8, pp.
674–692, 1999.
[2] C.-L. Pang and K. Y. Lam, “On using similarity for re-
solving conflicts at commit in mixed distributed real-time
databases,” Proceedings of the 5th International Confer-
ence on Real-Time Computing Systems and Applications,
1998.
[3] G. K. Attaluri and K. Salem, “The presumed-either two-
phase commit protocol,” IEEE Transactions on Knowl-
edge and Data Engineering, Vol. 14, No. 5, pp. 1190–
1196, 2002.
[4] J. Gray and A. Reuter, “Transaction processing: Concepts
and technique,” Morgan Kaufman, San Mateo, California,
1993.
[5] J. Gray, “Notes on database operating systems,” Operat-
ing Systems: An Advanced Course, Lecture Notes in
Computer Science, Springer Verlag, Vol. 60, pp. 397–
405, 1978.
[6] P. Misikangas, “2PL and its variants,” Seminar on Real-
Time Systems, Department of Computer Science, Uni-
versity of Helsinki, 1997.
[7] I. Lee and Y. H. Yeom, “A single phase distributed com-
mit protocol for main memory database systems,” 16th
International Parallel & Distributed Processing Sympo-
sium (IPDPS), Ft. Lauderdale, Florida, USA, 2002.
[8] C. Mohan, B. Lindsay, and R. Obermarck, “Transaction
management in the R* distributed database management
system,” ACM transaction on Database Systems, Vol. 11,
No. 4, 1986.
[9] N. Soparkar, E. Levy, H. F. Korth, and A. Silberschatz,
“Adaptive commitment for real-time distributed transac-
tion,” Technical Report TR-92–15, Department of Com-
puter Science, University of Texax, Austinm, 1992.
[10] R. Gupta, J. R. Haritsa, and K. Ramamritham, “More
optimism about real-time distributed commit processing,”
Technical Report TR–97-Database System Lab, Super-

U. Shanker ET AL. 263
computer Education and Research Centre, Indian Institute
of Science, Bangalore, India, 1997.
[11] R. Gupta, J. R. Haritsa, K. Ramamritham, and S. Seshadri,
“Commit processing in distributed real time database
systems,” Proceedings of Real-Time Systems Symposium,
IEEE Computer Society Press, Washington DC, San
Francisco, 1996.
[12] J. R. Haritsa, K. Ramamritham, and R. Gupta, “The
PROMPT real time commit protocol,” IEEE Transaction
on Parallel and Distributed Systems, Vol. 11, No. 2, pp.
160–181, 2000.
[13] U. Shanker, M. Misra, and A. K. Sarje, “Distributed real
time database systems: Background and literature re-
view,” International Journal of Distributed and Parallel
Databases, Springer Verlag, Vol. 23, No. 2, pp. 127–149,
2008.
[14] B. Qin and Y. Liu, “High performance distributed real
time commit protocol,” Journal of Systems and Software,
Elsevier Science Inc., pp. 1–8, 2003.
[15] K. Ramamritham and P. K. Chrysanthis, “A taxonomy of
correctness criteria in data-base applications,” Journal of
the Very Large Data Bases, Vol. 5, pp. 85–97, 1996.
[16] B. Qin, Y. Liu, and J. Yang, “A commit strategy for dis-
tributed real-time transaction,” Journal of Computer Sci-
ence and Technology, Vol. 18, No. 5, pp. 626–631, 2003.
[17] U. Shanker, M. Misra and A. K. Sarje, “SWIFT - a new
real time commit protocol,” International Journal of Dis-
tributed and Parallel Databases, Springer Verlag, Vol. 20,
No. 1, pp. 29–56, 2006.
[18] U. Shanker, M. Misra, A. K. Sarje and R. Shisondia,
“Dependency sensitive shadow SWIFT,” Proceedings of
the 10th International Database Applications and Engi-
neering Symposium, Delhi, India, pp. 373–276, 2006.
[19] O. Ulusoy, “Concurrency control in real time database
systems,” PhD Thesis, Department of Computer Science,
University of Illinois Urbana-Champaign, 1992.
[20] U. Shanker, M. Misra, and A. K. Sarje, “Hard real-time
distributed database systems: Future directions,” Com-
munication Network, Department of Electronics & Com-
puter Engineering, Indian Institute of Technology Roor-
kee, India, pp. 172–177, 2001.
[21] D. Agrawal, A. El Abbadi, R. Jeffers and L. Lin, “Or-
dered shared locks for real-time databases,” International
Journals of Very Large Data Bases, Vol. 4, No. 1, pp.
87-126, January 1995.
[22] Christoph Reinke, Nils Hoeller, Jana Neumann, Sven
Groppe, Volker Linnemann and Martin Lipphardt, “Inte-
grating standardized transaction protocols in ser-
vice-oriented wireless sensor networks,” Proceedings of
the 2009 ACM symposium on Applied Computing,
Honolulu, Hawaii, pp. 2202-2203, 2009