Orphan Elimination in Distributed Object-Oriented

Systems
Ahmed E<. Ezzat
He,wlett-PacEard Laboratories
1501 Page M i l l Rd.
Palo Alto, CA 94303
ezzat @hplabs.hp.com

Abstract sively in the distributed transaction management con-

T l i c orpknn deiectaon a i i d elzniziintioii asslie has been ad-
dressed eriensrziely an t h e dasirzbuted transaction mnn-
o g c i n e n t c o n i e x t a n d more r e c e n t l y a n t h e distributed
sysleins context w i t h t h e RYC framework. Aiz or-
p h n i i in n distrabzited object-oriented npplacaizons eiiva-
ronineni as ai1 ohject tuhtcli is created by n i i a p p l a c a t f o n
ani1 con t a n u e s to ed isi beyond t h e applacataon’s lifelame.
This puper addresses o i p h a i i d e t e c t i o n a n d e l i m i n a t i o n
l o r applac(rtioiis an n distrzbutcd ol)jcct-orzeiited systeni.
Mrc a p p l y o a r m o d e l f o r n disiribuied U n i ~ / / / c + + eiiiia-
roiiiiwiit, but the model t s g e i c m z l a n d can be applzed to
o t 11 r dastrz h 11 1 ed o b j cct- o ri e TI 1 c.d 51/ s t e ni s
1 Introduction
A tl i st,ri 11 11t e d sy st ein consists of inu 1ti ple computers
(called host,s) that, communicate t,hrough a network. A
tlist,ributed applicat>ionis one whose components reside
and esecut,e at multiple hosk in a distributed syst,em. In
a dist,ribut,ed object,-orient,ed a.pplicat,ion environment,
we envision the objec,t-oriented programming language
to lie t,he view of the application programmer in a pos-
sihly heterogeneous distribut,ed object, system.
An orphan in a distrihut,ed object-oriented applica-
tion environment is a nowpersistent object which is
created by an application and continues to exist be-
yond t,he application’s lifetime. The orphan detec-
tion and elimination issue has been addressed exten-
text [Herlihy 87, Herlihy 89, Liskov 87, McICendry 86,
Mueller 83, Walker 841 and inore recent,ly in the dis-
tributed systems context within the RPC frame-
work [Birrell 83, Casey 86, Lainpson 81, Panzieri 88,
Ravindran 89, Shrivastava 831.
A widely accepted approa.ch in constructing reli-
able distributed programs is the use of atomic actions
(also called tra.nsactions). Atomicity encompa.sses three
properties: serializahilit,y, rec.overability, and permu-
nence of effect. S e r i n l i s a b i l i t y [Gray 78, Bernstein 81,
Papadiinit,riou 791 iiiea.iis that the execution of one ac-
t8ivitynever appea.rs to over1a.p or contain the execution
of another activity. Recozrerubility niea.iis that the over-
all effect of an a.ct,ivityis all-or-nothing, and p e r m a n e n c e
of effeci means that once an act,ioii comniited its effect
will survive fa.ilures [Bernstein 83, Att,ar 84, Gray 811.
In a distributed transaction system, ac orphan can be
created because of crashes or aborted transactions. Or-
phans in such an environment are undesirable because
they are an activit,y executing on behalf of an aborted
transaction, and they can introduce unnecessary delay
or deadlock by holding locks needed by nonorphans. In
that sense, it is not only desirable to eliminate orphans,
but also it should be done in a tiniely manner.
There have been many algorithms for orphan elim-

4M
0 1990 IEEE
0-8186-2088-9/90/0000/0403/$01.00
in;ilt.io:? iii n distribute~ltransact~ioi~
cnvironnwnt: en-
ye7 algorit3hms [Herlihy 89, McICeiidry 861 which use
real-time clodis to ensure t,liat orphans are eliminated
within a fixed durat,ion, lazy aIgorit,hms [Herlihy 89,
McIiendry S6] which use !ogical clocks to ensure that
orphans are eventually eliminated as information prop-
agates through the syst,em, and a topological change al-
gorithm suita.ble for dealing with orphans resulting from
net:work pa.rtit,ioning [Mueller 831 in a dist,ributed trans-
act,ion system. Muelier's algorithm is driven by both the
t,ransactionhome sites and tlie transaction synclironiza-
tion sites (TSS) for the different, files opened from the
1 ransaction.
Outside t>h.etransaction doniain, t,he orphan elimina-
tion problem was first identified by Birrell [Birrell 831,
and solutions based on timeouts have been proposed by
Lampson [Larnpson 811 and Ra.jdoot [Panzieri 881. De-
pending on h e RPC semant,ics in a dist,ributed system,
additional requirements might) be needed for correct,ness
criteria. In particular, for ut niost once calls, not only
should orphans be aborted, t,he almtioii must include
undoing of a.ny side effects that inay have been pro-
duced [Panzieri 881. Wallw [Wallter 841 has proposed a
transaction-based orphan elimina.tion scheme that dy-
namically tracks dependencies a.mong transactions. His
scheme uses timeouts to keep the information sent in
messages t,o a ma,nageable level.
In a conveiitioiial transaction system, orphans have no
impact, on d a t a consistency, where a transaction does
not interact with the outside world until it commits.
However, in a general purpose distributed system, such
inconsistencies may he more prohlema.tic. For exam-
ple, the Argus system [Liskov S3] supports a method-
ology in which user-defined a.tornic data, types are ini-
plernent,ed by a mixture of atomic and nonatomic data
types at a lower level. In t,he absence of an orphan
elimination sc.heme, the implementor of such a. type is
404
responsible for ensuring that transient incmsistencies in
the atomic components do not produce permanent in-
consistencies in the nonatomic components. An orphan
elimination scheme based on Walker's method has been
implemented as part of the Argus system [Liskov 871 to
deal with that issue.
This paper addresses orphan detection and eiimina-
tion for applications in a dist,rihut,edobject-oriented sys-
tems. We apply our model for a distributed lJnix/C++
environment., but the model is general and ca.n be ap-
plied to other distributed object-oriented systems. The
paper is organized as follows. Section 2 describes the
background for this work and gives definitions for the
terminology used in t,he paper. Section 3 presents the
problem definition. Section 4 discusses our model. Sec-
tion 5 uses a simple example in a distributed Unix/C++
enviroiiment, to describe our model in more detail, and
we conclude hy a siimn-iary in Sect,ion 6.
2 Background and terminology
In this section, we define sonie t r r n ~ sused by our model
in this paper.
2.1 Iiiiplenientatioii set
An implementmationset is an object with a well defined
interface representing the traditional Unix process ab-
straction in an object-oriented system environment. An
iniplementation set contains many objects (persistent
a.nd non-persistent), and exports operations to admin-
ister these objects as well as control migrating objects
between different implementation sets. Implementat'ion
sets are uniquely identified in the system by a unique
I S - i d , i.e., corresponding to Unix process-id.
2.2 Distributed thread of control
'Traditional threads [Cooper 881 will be referred to as
physical threads in this paper as they have their own
physical stacks. Typically, a physical thread is uniquely
identified within a process by a t h r e a d - i d . Distributed
thread (dtlwead) represents the sequence (flow) of events
or invocations by an application (one or more physical
threa.ds) in a distributed system, i.e., the dthread notion
is a virtual thread of control and it does not own private
physical stacks, rather it uses potentially many of the
st,acks belonging to existing physical threads.
Ilthreads are created upon invoking operations on ob-
jects asynchronously, i.e., an application might have
a tree of distributed threads. A distributed thread
terminates when the method originally invoked asyn-
chronously terminates.
The not,ion of dthread is used to help in tracing events
and cleaning orphans later. Each dthread'has a unique
identifier in the syst,em (dthrea.d-id) assigned at. cre-
ation time in a decentralized manner using the tuple
<machine-id : IS-id : thread-id>'.
2.3 Factories
Fact,ories are objects specialized in creating objects of a
spwific class, i.e., interface and implementation. They
provide a uniform model for creating objects in a dis-
tribukd environment. This model allows the program-
mer to create objects t,he same way independently of
where they are created (i.e., in the local address space
or in a different one).
In traditional C++, the operator new(> creates a.n
jnstance of a class only in the same address space. Fac-
In a Unix context, machine-id corresponds to a host-id, IS-id
corresponds to a process-id, and thread-id is a unique ident.ifier
to a physical thread within that process.
405
tories are responsible only for creating objects2 of a spe-
cific class. The interface to a factory object has one
method ( c r e a t e ( ) ) , which creates insta.nces of a partic-
ular class in the same address space where the factory
is. The c r e a t e ( ) method can be thought of as a wrap-
ping to the n e w 0 operator in C++. Once the program-
mer has a reference to a factory object, the programmer
can create objects of that specific class by invoking the
c r e a t e ( ) method on t8hat factory independent of the
factory location.
2.4 Persistent objects
Persistent objects are objects whose lifetime is indepen-
dent of the lifetime of the thread which created them.
On the other hand, non-persistent object's lifetime is
tied to the lifetime of the thread which created them, for
example, in traditional Unix/C++ environment objects
are deleted automatically when the process terminates.
3 Problem statement
The current memory management model for C++ is
to reclaim memory for all objects in a given process
(address space) upon process termination. This model
would not, apply for persistent objects as by definition a
persistent object's lifetime is independent of the lifetime
of the dthread which created it.
On the other hand, applying the current C++ mem-
ory management model to non-persistent objects is a
much more difficult problem and needs to be resolved.
For example, consider a dthread that creates a remote
non-persistent object and then terminates. This remote
object becomes an orphan and needs to be reclaimed.
Next section presents a lazy scheme where orphans are
2Notice that factories only create objects and do not delete or
manage them. Deleting an object will be dealt with in this paper
in a later section.
guaranteed t o be eliiilinated ai the termination of the
dthread which created them.
The issue of managing the application objects’ st>orage
is fortunately limited only to two scenarios. an applica-
tion object created as a result of remote invocation on
a factory object, and an object migrating from one im-
plementation set to another. We envision one approach
for dealing with both scenarios and in our discussions
we will focus only on the factory invocation scenario
To administer globally the storage of dist,ributed ap-
plication objects, we are adding two objects per imple-
mentation sets to help in performing this administrative
function. These two objects are either created trans-
parently as part of initializing new implementation sets
or explicitly by requiring applications to call a library
function from main(). Each of tthe two ohjects has a
database as part of their s t a k representing the infor-
mation about a subset of the objects in the syst,eni, and
each object has a set of methods to query their database.
These two object,s enable tracking where dt,hrea.ds had
created objects and how lo get t,o them. The operation
of how they are used is discussed in det,ail next, section
through a simple example. The following is a descrip-
tion of these two objects and their interfaces’ methods
description.
1. Local directory (LD) object: t,his is an ob-
ject per implementation set. The object’s state
contains informat,ion about all local objects in
this implementation set which are created in re-
sponse to requests from other implementation sets.
An entry in this object’s database is represented
as a tuple <dthread-id : IS-id : GID : local
o b j e c t r e f e r e n c e > . Figure 1 represents t,he lo-
406
cal &rectory interface declaration. Referring to
figure 3 , an entry in the local directory object’s
database in IS2 is described below:
0 Dthread-id: is the identification of the dthread
(dthreadl) which created this object ( o b j e c t l )
in this implementation set (IS2).
0 IS-id: is the iniplenientation set (El) from
which the dtliread initiated the creation of this
object (objectl).
e GID: is the object (objectl) global unique-id.
0 Local object reference: is a reference to the
local object (objectl) iri this implementation
set (IS2).
The a d d - e n t r y ( ) method inserts a tuple in t.he lo-
cal direct,ory’sstate about how a local object in this
implementalion set was created.
The different flavors of the d e l e t e - e n t r y ( )
method delete the appropriate local object(s) in
this implenientatio 1 set and clean their correspond-
ing entries in this local directory object.
2. Remote directory (RD) object: this is an oh-
ject per implementation set. The object’s state
contains information about remotely created ob-
jects from this implementation set. An entry
in this object’s database is represented as a tu-
plecdthread-id : G I D : remote LD r e f e r e n c e
: remote o b j e c t r e f e r e n c e > . Figure 2 repre-
sents the remofe direct0 y interface declaration.
Referring t o figure 3, an entry in the remote di-
rectory object’s database in IS1 is described below:
0 Dthread-id: is the identification of the dthread
(dthreadl) which created the remote object
(objectl).
0 GID: is the object (object ) global unique-id.
inteif acc loc,al-directory =
add-entry(dthread-id ID, IS-id IS, gid-t GID, ref -t LCL-OBJ-REF) ,
delete-entry(ref-t LCL-OBJ-REF) ,
delete-entry(gid-t GID),
delete-entry(dthread-id ID, IS-id IS);

Figure 1: A local directory interface declaration

interface remote-directory =
add-entry(dthread-id ID, gid-t GID, ref-t RMT-LD-REF, ref -t RHT-OBJ-REF) ,
delete-entry(ref-t RMT-OBJ-REF),
delete-entries(ref-t RMT-LD-REF),
check(dthread-id ID) ;

Figure 2: A remote directory interface declaration

e R,eiriot,e LD reference: is a remote reference to to get to them to delete t8he111. Access to these two
the loml directory object, in the implement,;?- directory objects is transpa.rent to the application pro-
tion set, where objectl is (i.e., LU2). granimer (i.e., the application need not t o do explicit

e Re1not.e object reference: is a. remote reference operations on these directory objects) and they are only

to t8heact,ual object (i.e., objectl) in 1’32.
The add-entry() method insert#sa tuple in t,he re-
mote directory’s st,ate about, a.n ol,ject, creat,ed re-
iiiot,ely from this iniplemeii tation set,.
The delete-entry() inet.hod delet,es a reiiiot,e oh-
ject and cleans the appropriate direct,ory entries.
The delete-entries() method deletes all entries
i n t,liis remote direct,ory object, for objects created
from this implenientlation set in a specific remote
implenientmationset.
accessed from system funct,ions. The following a.re three
scenarios illustrat<ingwhen these directory objects are
a.ccessed:
o On creating a remote object, the factory’s
create() method initializes an entry in the Iocal
directory object, for the implementation set where
the factCoryis. Back on the client side, the c r e a t e 0
method will initialize an entry in the remote di-
rectory object, before returning a reference to the
applicatioii.

The check() met,hod returns an eiit,ry from the re-

motmedirect,ory object corresponding to a specific
dt,hread-id.
A new t,wo library functions are supplied as part of the
system, one is t,o eliminate orphan objects on dt,hread
teriilina.tion (terminate()) a n d the other is used for es-
plicit object, deletion (kill()). These library functions
will invoke operations on the appropriate directory ob-
jects to track where dt,lireads created objects a.nd how
0 On dthread termination, the terminate0 library
funct,ion invokes operations on the appropriat,e di-
rectory objects to track and delete orphans, and
then clean the appropriate entries from these di-
rectory objects’ state.
0 On explicit object deletion, the kill() library
function invokes operations on the appropriate di-
rectory objects to track and delete the object (i.e.,
if the object is remote), and to clean the appropri-
 ate ciitries from thc dizectory objects’ statme. in the remote directory object’> datahaFe in IS1
c d t h r e a d i : G I D : *LD2 : * o b j e c t l > .

5 Example o A reference to the remote object o b j e c t l is re-

turned to the applications.
‘To illustrate how an implemented version of our model
will work in a distributed l i n i x / C + t environment, we 5.2 Dthread teriiiination
use a simple example (figure 3) where, dthreadl created
ir, IS1 creates (objectl) in IS2, and t,hen terminates. In In the above example, upon dthreadl termination in
this simple example, we assume that the application IS1, the t e r m i n a t e ( ) library function is called to elini-
has already a reference to f n c l o r y l . The example will inate all non-persistent objects created by dthreacll
discuss in detail how remote objects are created, how in the system which otherwise become orphans. The
orphans are eliminated ;it dthread termination, and how t e r m i n a t e ( ) function checks (see figure 4) if there are
objects are deletmeclexplicitly. entries in the remote directory object ( R D l ) belonging
to dthreadl. If 110 entries are found, then dtlireadl ter-
5.1 Remote object creation minates and we are done.

For every entry found in the RD1 object belonging

Objects axe created by iiivolting the c r e a t e ( ) method
to dtlireadl, t*he check(1D) operation ret,urns a refer-
on the appropriate factory. Jn this example (see figure
ence (RMTLD-REF) corresponding to a local directory ob-
3): dthreadl in IS1 invokes the c r e a t e ( ) method on
ject (i.e., LD2). The t e r m i n a t e 0 function invokes t,he
factory1 in JS2 and as a result, objcct,l is created in
delete-entry(G1D) method on the local directory ob-
IS2, and a reference to t,he remote object, is ret#uriieclt,o
ject, in the remote implementation set (IS2). This will
dthreadl. In order to keep track of remote objects, ap-
result in deleting object1 and t8hecorresponding ent,ry
propriate entries in the direct’ory ohjects are initialized
from t,he local directory object in IS2. With no en-
as follows: The following steps occur t,ransparent,lyto
tries in t,he remotmedirect,ory object, in IS2 correspond-
[#heapplication:
ing to dthreadl, the d e l e t e w e n t r y ( )operat.ion is coni-
pleted. Finally, t,he t e r m i n a t e ( ) function invokes the
T ~ Ifactory
P in IS2 after creating the desired object
d e l e t e - e n t r i e s ( 1 method on the remote directory oh-
(ohjrctl) will invoke the a d d - e n t r y ( ) operation 011
ject in I s 1 t,o clean all entries with RMTLDAEF field
LD2 object. This will add an entry ill the local di-
equal t o the returned reference from the check() oper-
rectory object’s database in IS2 ( d t h r e a d l : IS1
ation (i.e., LD2).
: GID : * o b j e c t i > .
Notice that the d e l e t e - e n t r y ( ) operation on the lo-
In the RPC message returning the reference to ob-
cal directory object after completing its work in IS2, it
jectl, the factory will add a reference to LD2 in the
checks if there are entries in the remote directory object
mess age.
at IS2 belonging t o dthreadl. If there are entries. the
On crossing machine boundary t,o IS1, An d e l e t e - e n t r y ( ) is invoked on the new local directory
add-entry() operation is invoked on the remote object as we discussed earlier. This will take care of
directory object in IS1. This will add an entry nested object creation across multiple implementation

408
l o c a l d i r e c t o r y o b j e c t (LDI)
l o c a l d i r e c t o r y object(LD2)

I remote d i r e c t o r y
o b j e c t (RDl) 1 I \
\
I I
dthr I I 4
'
remote d i r e c t o r y

!
I

0: I
obj e c t (RD2 )
: 0: I

---*a
0
I
._----
I

I
I
I
I I
I

I
I
I
I
J
I
I
I
I I I / I
' I I I J
I / I / I
I I I / I
I f I / I

. n a tE

\ completed o r p h a n s
elimination

IS1 IS2

Figure 3: Creating a remote object and orphan reclaimation

409
terminat,e(dthread-id ID)
begin

ref-t RMT-LD-REF;

while(RMT-.LD-REF : = remote-directory->check(ID))(
I1MT_LL)_REF->delete_entry(ID, IS);
remote_directory->delete-entries(RMT-LD-REF);
3
end ;

Figure 4: The terminate library function

sel,s in a distributed system.
5.3 Explicit object deletion
Factories are used to provide a uniform method of crest,-
ing objects in a distributed system. They are responsi-
ble for creat,ing objects and iiot, for managing or deleting
them. This is because we believe that the programnier
should not have to remember the factory reference in
order to be able to delete an object. Iiistead, we intro-
duce a new kill() function to replace the delete()
function in C++.
If the object t o be deleted is remote (i.e.,
d t h r m d l in IS1 is deleting o b j e d l in 1S2, the
kill(obj2ef) function (see figures 3, 5) invokes the
delete-entry(obj2ef) method 011 the remote direc-
tory (R,Dl) in this implementation set (El). This in
turn invokes the delete-entry(G1D) method on the ap-
propria.te remot,e LD object (i.e., LD2). The net result
is deleting t,he remote object (objectl) and cleaning the
appropriate entries in the directory objects, i.e., an en-
t8ryin the local directory object in IS2 and a n entry in
the remote directory object in IS1.
On the other hand, if t,he object, is local (e.g.,
dthreadl in IS2 is deleting object 1 and obj -ref is a ref-
erence to objectl), the kill(objxef) function invokes
the delete-entry(objief) method on the local direc-
tory object in tjhis implerneritatiori set (i.e., IS2). The
net result is deleting the object (objectl) and cleaning
the appropriate entry i n the local directory object (i.e.,
IS2).
6 Conclusion
The orphan detection and elimination issue has been
investigated extensively in the distributed transaction
contest as well as in the distributed system cont,ext
within t,he R P C framework. In this paper we ex-
tended this investigation to a general distributed object-
oriented application environment. Orphans in a dis-
tributed object-oriented application environment are
objects which are created by the application and con-
tinue to exist beyond the application’s lifetime. Orphan
objects in a distributed object-oriented application en-
vironment correspond t o activities which continue to ex-
ecute on behalf of aborted transactions in a distributed
transaction system.
We presented a simple and a general model for de-
tecting arid eliminating orphans in a distributed object-
oriented application environment. Also, we presented a
simple example to illustrate how our model would work
in a distributed Unix/C++ application environment.
An implenientsatlionof our model should not add much
overhead; we are planning t o implement this model in

410
void* kill(ref,t obj-ref)
begin
i f (obj-ref->is-remote())
remote-directory->delete-entry(obj-ref)
else
local-directory->delete-entry ( o b j - r e f ) ;
end;
Figure 5: The kill function
the near future as soon as the necessary platform envi-
ronment is completed.
References
[Attar 841 R. Attar, P.A. Bernstein and N.
Goodman, “Site Initializa.tion, Re-
covery, and Backup in a Distributed
Database System,” IEEE Trans. on
Soft. Eng, vol.SE-10, No. 6, pp.
645-650, (Nov. 1984).
[Bernstein 811 P.A. Bernstein and N . Good-
man, “Concurrency Control in Dis-
tributed Database Systems,” ACM
Computing Surveys, vol. 13, No. 2,
pp. 185-221, (June 1981).
[nernstein 831 P.A. Bernstein, N . Goodman and
V. Hadzilacos, “Recovery Algo-
rithms for Database Systems,”
Proc. of the IFIP 9th World
Computer Congress, pp. 799-807,
(1983).
[Birrell 831 A.D. Birrell and B.J. Nelson,
“Implementing Remote Procedure
Calls,” Operating Systems Review,
vol. 17, no. 5, (Oct. 1983).
[Casey 861 L.M. Casey, “Comments on ”The
Design of a Reliable Remote Pro-
cedure Call Mechanism” ,” IEEE
Trans. on Computers, vol. c-35,
No. 3, pp. 283-285, (March 1986).
[Cooper 881 E. Cooper and R. Draves, “C-
Threads,” Carnegie-Mellon Univer-
sity, Tech. Rep. CMU-CS-88-154,
(March 1988).
[Gray 781 J.N. Gray, “Notes on Data Base
Operating Systems,” in Operating
411
;
Systenas-an Advanced Course, R.
Ijayer, R..M. Graham, and G. Seeg-
muller, Springer Verlag, New York,
pp. 393-48 1, ( 1978).
[Gray 811 -1. Ciriiy, 1’. McJones, M. Rlasgen, n.
I,ilrtlsiLy, 11.. Imic, T. Price, F. Put,-
is0111 iltl(l I . Tkaiger, “The Recovery
MiLtl;l.gf:r of the System R. Database
M ~ L I iI ~ g c,”r A CM Computing Sur-
vey.~, vol. 13, NO. 2, pp. 223-242,
(.Iiiric 1981).
[Herlihy 871 MA’. IIerlihy, N. Lynch, M. Mer-
ritt,, arid W . Weihl, “On the Cor-
rectness oi Orphan Elimination Al-
gorithms,” Symp. on Fault Toleraiit
Computing, pp. 8-13, (1987).
[Herlihy 891 M.P. Herlihy, M.S. McKendry,
“Timestamps-Based Orphan Elimi-
nation,” IEEE Trans. on Soft.Eng,
vol. 15, NO. 7, pp. 825-831, (July
1989).
[Lampson 811 B. Lampson, “Remote Procedure
Calls,” Lecture Notes in Computer
Science 105, Berlin: Springer-
Verlag, pp. 365-370, (1981).
[Liskov 831 B. Liskov and R. Scheifler,
“Guardians and Actions: Lingus-
tic support for robust, distributed
progran?s,” ACM Trans. Program.
Lung. and Syst., vol. 5, No. 3, pp.
381-404, (July 1983).
[Liskov 871 B. Liskov and R. Scheifler, E.
Walker, W.E. Weihl, “Orphan de-
tection,” 17th Symp. Fault Tolerant
Computer Systems (FTCS), pp. 2-
7 , (July 1987).
[McKendry 861 M.S. McKendry and M. Her-
lihy, “Time-Driven Orphan Elim-
ination,” Fifth Symp. on Relia-
 hility in Distrihted Sofi.ware a n d
Database Sysiems, pp. 42-, (Jaii-
uary 1986).
[Mueller 831 E.T. Mueller, J.D. Moore, and
G.J. Popek, “A Nested Transaction
Mechanism for LOCUS,” Proc. of
the Ninth AGM Symp. o n Operat-
ing Systems Principles, pp. 71-85,
(October 1983).
[Paiizieri 881 F. Panzieri and S. Shrivastava,
“Rajdoot: A Remote Procedure
Call mechanism Supporting Or-
phan Detection and Killing,” I E E E
Trans. on Soft. Eng, vol. 14, No. I ,
pp. 30-37. (January 1988).
[Papadimitriou 791 C.H. Papadimitriou, “The Serializ-
ability of Concurrent IIat,abasc
412
Updates,” J. ACM, vol. 26, No. 4.
pp. 631-653, (Oct,ober 1979).
[Ravindran 891 I<. Ravindran and S.T. Chanson,
“Failure Transparency in Remote
Procedure Calls,” IEEE Trans.
Compt., vol. 38, No. 8, pp. 1173-
1187, (August 1989).
[Shrivastava 831 S. Shrivastava, “On the Treatment
of Orphans in a Distributed Sys-
tem,” Third Symp. 07). Reliability in
Distributed Soflutare and Database
Sysfems, pp. 155-162, (Nov. 1983).
[Walker 811 E.F. Walker, “Orphan detection in
t,he Argus system,” Massachusetts
Inst. technol., Lab. Comput. Sci.,
Tech. Rep. TR-326, (June 1984).