Quorum-based locking protocol for replicas in object ... - CiteSeerX

Quorum-based Locking Protocol for Replicas in Object-based Systems K a t s u y a Tanaka a n d Makoto Takieawa Dept. of Computers a n d Systems Engineering Tokyo Denki University e-mail {kat su, t aki}@t akilab.k.dendai.ac.j p conflicting with t is issued, every instance o f t not performed so far is required t o be performed. “Nt Nu > U’’ if t and U conflict. Even if t or U upNu a only dates the object, i.e. write, Nt if t and U are compatible. The authors [17] discuss a version vector t o identify which methods are plerformed on each replica. However, it implies larger overhead. In this paper, we discuss a simpler protocol to exchange methods among replicas. In the object-based system, methods are invoked in a nested manner. Suppose a method t on ant object x invokes a method U on another object y . Let X I and x2 be replicas of x and y1 and yz be replicas of y . A method t is issued t o x l and x 2 . Then, the method t invokes U on y1 and y2. Here, U is performed twice on each replica although U should be performed only once on each of the replicas y1 and y2 if U updates the replicas. Otherwise, y gets inconsistent. This is a redumdant invocation. In addition, an instance of t on 51 issues U t o its own quorum Q1, and a n other instance of t on 2 2 issues to Q2 where IQl/ = IQ21 = Nu, but Q1 # Q2. More number of replicas are locked than the quorum number Nu, i.e. 1 0 1 U Q21 >_ Nu.If U furthermore invokes another method, the number of replicas to be locked is more increased and eventually all the replicas are locked. This is a quorum explosion. We discuss how t o resolve the redundant invocations and quorum explosions in nested invocations of methods on replicas. In section 2, we overview the traditional quorum-based protocol. In section 3, we discuss the exchanging procedure in the object-based systems. In section 4, we discuss how to resolve the redundant invocation and quorum explosion. In section 5 , we evaluate the quorum-based protocol.

Abstract W e discuss how to lock replicated objects by extending the quorum concept and perform methods o n replicas in a nested invocation. Each method i s issued to a quorum. If a pair of methods are compatible, their quorums may not intersect in our protocol even i f one of the methods is a n update type. If a method t is invoked o n multiple replicas and each instance of t invokes another update method U , U is performed multiple times o n replicas and then the replicas get inconsistent, i.e. redundant invocation. I n addition, since each instance issues a request to its own quorum, more number of the replicas are locked than the quorum number, i.e. quorum explosion. W e discuss how to resolve the redundant invocations and quorum explosion.

+

1. Introduction Objects are replicated in order to increase the reliability, availability, and performance in distributed object-based applications [16]. In the two-phase locking (2PL) protocol [3,7], one of the replicas for read and all the replicas for write are locked. In the quorum-based protocol [9], quorum numbers N , and N,,, of the replicas are locked for read and write, respectively. The subset of the replicas is a quorum. Here, a constraint “ N , N,,, > U” for the number a of the replicas has to be satisfied. An object is an encapsulation of data and methods for manipulating the data. A pair of methods of an object conflict if the result obtained by performing the methods depends on the computation order. Suppose a pair of update methods t and U are issued to replicas x1 and 2 2 of an object x . The method t may be performed on one replica q and U on another 5 2 if t and U are compatible. Here, the state of x1 is different from ”2.. The newest version of x1 and 2 2 can be obtained by exchanging methods t and U. As long as t and U are issued, the methods are performed on replicas in their quorums. If some method z1

+

0-7695-1065-5/01 $10.00 0 2001 IEEE

+


3 . For example, a write request is issued to a quorum Qw = { X I , 22) and a read request is issued t o a quorum Q , = ( 2 2 , 2 3 ) . The read and write methods are surely performed on the replica x2 in Qr n Q w while only write and read are performed on X I and 2 3 , respectively. Each replica xi has a version number b;. b; is incremented by one each time write is performed on xi. If a request t is issued, a replica x i whose version number b; is maximum in a quorum Qt is found. If the request is read, the value U; of xi is read. If the request is write with a value v , v is written into the replica x;. The version number b; is incremented by one. Then, b; is sent t o the replicas in Q,,,. Figure 1 shows the protocol.

+

Figure 1: Quorum-based protocol.

decrement

increment

f-ijIl3

3. Object-Based Quorum Protocol 3.1. Extension of quorum concept

An object supports methods for manipulating the object. We extend traditional quorum-based locking protocols for primitive methods read and write on simple files t o methods of objects. Let us consider a counter object c which supports three types of methods increment ( i n c ) , decrement ( d e c ) , and display ( d s p ) . Suppose there are four replicas c1, c2, cg, and c4 of the counter object c, i.e. the cluster R, is {CI, c2, cg, c4). According t o the traditional quorum-based theory, inc and dec are considered t o be write methods because they change the state of the object C. Hence, Nine Ndec > 4, Ndsp Ninc > 4, and Ndsp Ndec > 4. For example, Nine = Ndec = 3 and Ndsp = 2. Since dsp conflicts with inc and dec, Ndsp Nine > 4 and Ndsp Ndec > 4 in our protocol [Figure 21. However, inc and dec are compatible because the state obtained by performing inc and dec is independent Ndec 5 of the computation order. Hence, Nine 4,e.g. Nine = Ndec = 2. Suppose Qinc = {c1, c2} and Qdec = {cg, cq}. Since either inc or dec is performed on replicas in the quorums, the states of c1 and cg are different. However, if dec is performed on c1 and c2 and inc on cg and c4 here, the states of c1, c2, cg, and c4 can be the same. This is an exchanging procedure where every method t performed on one replica is sent t o other replicas where the method t is not performed and only methods compatible with the method t are performed. As long as only inc and dec are issued to the replicas, the exchanging procedure is not required t o be executed. Suppose dsp is issued t o three replicas c1, c2, and cg where Qdsp = { c l , c ~ , cg}. dsp conflicts with inc and dec. dsp cannot be performed on replicas c1, c2, and c3 because only inc is performed on c1 and c2 and dec on cg as shown at step 1 of Figure 3. Before performing dsp, dec has t o be performed on c1 and c2 and inc on cg. inc and dec can be performed in any order because they are compatible. Here, c1, c2, and cg get the same because both inc and dec are performed on every replica [2 of Figure 31. Then, dsp can be performed [3 of Figure 31. We discuss a new quorum-based locking protocol with the exchanging procedure. Quorums of an object x have t o satisfy the following constraint.

+

+

+

+

+

+

[Object-based Quorum (OBQ) constraint] If a pair of methods t and U conflict, Nt + Nu > a where a is the total number of the replicas. It is noted that Nt Nu 5 a only if t and U

display

Figure 2: Object-based quorums.

+

are compatible even if t or

197

U

is update. The OBQ

,. + .

:dec

. :

....

.. + . ,

:

inc:

a

.. + . .

:

. inc: ___.

Figure 3: Exchanging procedure. constraint implies the following properties: [Property] Every pair of conflicting methods t and u of an object z are performed on at least k (= Nt Nu - U ) replicas in the same order. 0

+

3.2. Exchanging procedure

A log Lh is supported for each replica Zh where a sequence of update methods performed on Z h are kept in record. Initially, Lh is empty, i.e. Lh = (1. Suppose a method t is issued to the replica Zh. If t is an update method, t is stored in Lh, i.e. Lh = ( t ] . Here, let Lh be a sequence of update methods ( t h l , . . ,, thm] ( m 2 1). Suppose an update method t is issued to Zh. If t is compatible with every method in Lh, t is enqueued into Lh, i.e. Lh = (thl, . . ., thm, t ] and then t is performed on Z h . Thus, every pair of methods in Lh are compatible. Suppose t conflicts with some method thf and is compatible with every method thg ( g > f ) in Lh. There might be a replica Z k whose log Lk includes some method tkj which is compatible with every method in Lh but conflicts with t , and is not performed on Zh. Such a method t k j is required to be performed before t is performed on ~ h .Here, another replica Z k has a log Lk = (tkl, . . ., tkl] and t is issued to Zk. The method t conflicts with some method t k u and is compatible with every method t k g ( g > U). According to the OBQ property, every pair of methods th, in Lh and tkj in Lk are compatible. Here, t k j in Lk is referred t o as missing method for a method t on a replica Z h iff tkj is not performed on Z h and tkj conflicts with t [Figure 4(1)]. Here, every missing method tkj in Lk for the method t is required to be performed on the replica Z h before t is performed. Then, t is performed on Zh. All the methods conflicting with t are marked * in Lh and t is enqueued into Lh [Figure 4(2)]. Every pair of unmarked methods in a log are compatible. If an update method t is marked in every log, t was performed on every replica and some method conflicting with t has been performed after t. Hence, t is removed from every log.

Figure 4: Exchanging procedure. Let us consider four replicas c1, c2, c3, and c4 of the counter object c discussed in Figure 4. Here, N,,, I= Ndec = 2 and Ndsp = 3 according t o the OBQ constraint [Figure 21. First, a method increment (incl) is issued t o c1 and c2. Then, decrement (decl) is issued to c3 and c4. The methods are performed on the replicas and are enqueued into the logs. Here, L1 = L2 = (incl] and L3 = L4 = (decl]. Next, increment (inc2) is issued to c2 and c 3 . Since inc and dec are compatible, incz is performed on c2 and c3 and is enqueued into the logs L2 and L3. Here, L1 = (incl], L2 = (incl, inca], L3 = (decl, incz], and L4 = (decl]. Thus, as long as only increment and decrement are issued, they are performed on the replicas in their own quorums. Next, a method display (dspl) is issued to c1, c2, and c4. dspl conflicts with incl, inc2, and decl. Here, incz and decl are missing methods for dspl in c1. Hence, inc2 and decl are to be performed on c1. decl is performed on c2 and incl and incz are performed on c4. Here, c1, c2, and c4 are the same. Thus, only if a method conflicting with some method in a log is issued, the methods in the log are transmitted to other replicas. Then, dspl is performed on c1, c2, and c4. The methods incl, inc2, and decl are marked * in the logs L1, L2, and L4 because the methods conflict with dspl. Since dspl does not change the state, dspl is not enqueued into the logs, i.e. L1 = (*incl, *decl, *incz], L2 = (*incl, *inc2, *decl]; L4 = (*decl, *incl, *incz], and L3 = (decl, incl]. Then, dsp2 is issued to the replicas c2, c3, and c4. incl is not performed on c3 although incl is pel-formed on c2 and c4. Hence, incl is performed on c3. Here, c2 = c3 = c4. Then, dsp2 is performed on c2, c3, and c4. Here, L Z = (*incl, *inc2, *decl), L3 = (*decl, *inc2, *incl], and L4 = (*decl, *incl, *inc2]. The methods incl, inc2, and decl are marked in every log. That is, some method conflicting with the methods incl, inc2, and decl is performed on every replica after the methods are performed. The methods incl, inc2, and decl are removed from the logs. Then, L1 =. L2 = L3 = L4 = ( ] [Figure 51. A transaction T issues a request t to the replicas in a quorum Q t :

1. If every method in Lh is compatible with the method t , t is enqueued into Lh if t is an update one and Ack (acknowledgment) is sent

198

( i n c l , inca] ( * i n c l , *incz, *decl]

-7; (*decl, *incz, *incl] ( ]

(decl, incz]

(*decl, *incz, *incl]

Figure 5: Logs.

T requires incl to be performed on c4. Hence, T

)time1 (1) No conflict

1

C

sends inc;lo1 to c1, cz, and c4. Then, inc1 is performed on c4. *inc:lol is stored in the logs of c1, c2, and c4. When a transaction T issues another display (dspz) t o c1, c2, and c3, incYo1l is sent from c3 to the transaction T and *inc:lol is sent from c1 and c2 to T. Here, 0011 V 1101 = 1111. T sends inc:ll’ to every replica. Since every replica finds incl has been performed on every replica, *incl is removed from the log in every replica.

ltime

(2) Conflict

Figure 6: QB protocol. t o T. If T receives Ack messages from all the replicas in Q t , T sends Do to the replicas and then t is performed on the replicas. If there is some method in Lh which conflicts with t , L h is sent t o the transaction T. T collects the logs sent by a replica Xh, i.e. L = L U Ah. If T receives responses from all the replicas, T sends a log Lh’ = {t’ I t’ E ( L - L h ) and t’ conflicts with t } , i.e. missing methods for t on Xh to each replica Xh. A method in Lh’ is performed on Xh. Then, t is performed on Xh. Every method conflicting with t in Lh is marked.

4. Nested Invocation 4.1. Redundant invocation

In the object-based system, methods are invoked in a nested manner. Suppose there are replicas 21, . . ., x , of an object x and replicas y1, . . ., Yb of another object y and a method t of x invokes a method U of y . A transaction T issues a method t to replicas in the quorum Q t , say Nt = 2. Suppose t is issued t o replicas 2 1 and 22. Furthermore, t issues a request to replicas in the quorum of y to invoke a method U. Here, suppose Nu = 2. Let tl and tz be instances of the method t performed on replicas x1 and 22, respectively. Each of tl and tz issues a request of the method U t o replicas in a quorum of U. Here, let Qul and QU2 be quorums of U decided for the instances tl and t z , respectively, where IQul( = IQuz( = IQu/. Suppose Qul = Qu2 = {yl, yz}. The instances tl and t 2 issue the request U t o both replicas y1 and yz. Here, let ui1 and uiz be instances of the method U performed on replicas y1 and y 2 , which are issued by an instance t; (i = 1, 2 ) , respectively [Figure 71. If U is an update type, a state of y1 is inconsistent because two instances u11 and u21 from tl and t 2 are performed on yl, respectively. For example, U is a method by which the value of y is multiplied by two. The replica of y is finally multiplied by four since U is performed two times on y . This is a redundant invocation, i.e. a method on a replica is invoked by multiple

In Figure 6, a transaction T issues a reuqest t to replicas 51, . . ., x , in the quorum Q t . Figure 6 (1)shows that the method t is compatible with methods in every log. Figure 6 (2) indicates that t conflicts with methods in some log. Each object has to decide whether or not each marked method in the log is performed on every other replica. Each method t brings information dst showing on which replica t is performed. dst is represented in a bit map “ b l . . .b,” where “bk = 1” means that t is performed on a replica ck. For example, increment ( i n c l ) is issued to the replicas c1 and c2. Here, dst of incl is 1100. inci1O0 shows that incl is performed on c1 and C Z . In the exchanging procedure, the transaction T receives inc;lo0 from c1 and c2 after issuing display ( d s p l ) t o the replicas c ~c , ~and , c4. Since T knows incl is performed on c1 and C Z , i.e. 1100,

199

more number of replicas are locked. This problem is referred t o as quorum explosion. Suppose a method t on an object z invokes a method U on an object y. Let Quh be a quorum of the method U invoked by an instance t h of the method t on a replica z h . In order t o resolve the quorum explosion, a pair of quorums Quh and Quk have t o be the same for every pair of replicas Z h and 5 k where an instance of the method t is performed. If a quorum is a priori decided for a method t , i.e. Quh = Quk =T Q u , only the same replicas are manipulated for every instance of the method U. If some replica is faulty, a quorum for every method including the faulty replica is required to be changed. We take a following approach t o resolving the quorum explosion: Each replica has a same function rand for generating a same set of random numbers. That is, rand(i, n, a ) gives n random numbers out of 1, . . ., a for a same initial value

W Figure 7: Redundant invocation. instances of a method. Each method instance t invoked has a unique identifier (id@)). For example, i d ( t ) is composed of the local identifier of t , e.g. thread identifier o f t , method type of t , and identifier of x. Each transaction T has a unique identifier t i d ( T ) = t i d of T . If T invokes a method t , t is assigned a transaction identifier tid(t) = tid(T). Here, suppose a method t2 on an object 2 2 is invoked by a method instance tl on 51. t i d ( t 2 ) is given as a concatenation of i d ( t 1 ) and tid(tl),i.e. t i d ( t 2 ) := tid(tl).id(tl). Thus, the identifier t i d ( t ) shows an invocation sequence of method instances from T to t . Suppose t is invoked on a replica Z h . t is performed on 2 h as follows: 1. If t is performed on a replica xh, ( t , response o f t , t i d ( t ) ) is stored in the log Lh of Z h . 2 . If a method instance t' such that t i d ( t ) = t i d ( t ' ) is found in the log Lh, i.e. t and t' are

i. Suppose an instance t h on a replica Zh invokes a method U. For each replica 5 h , I = r a n d ( t z d ( t h ) , Nu,b) is obtained, where Nu is IQU\ and b is a total number of replicas, i.e. {yl, . . ., yb}. That is, I E 2{1*2*-1b}and 1 11 =: Nh. Then, a quorum Q h is constructed a:; {y; 1 E I}. Every instance invoked by a same instance has the same transaction identifier as presented in the preceding subsection. Hence, r a n d ( t i d ( t h ) , Nu, b ) = r a n d ( t i d ( t k ) , Nu,b ) for every pair of instances th and t k invoked by a same instance. AIL

instances of a same method and are invoked

instance

by a same instance, the response o f t ' is sent

th

of the method t on every replica

zh

issues a request of the method 'LL to the same quorum Quh = Q U . Hence, the quorum explosion is prevented [Figure 81. The transaction identifier t i d includes thread identifiers. Hence, the quorum of the method U can be differently constructed for each invoker o f t depending on t i d of the invoker. In this approach, each instance th on a replica Z h issues a request U t o Nu replicas of the object y . Since each of Nt instances of the method t issues Nu requests, totally Nt . Nu requests are transmitted. We try to reduce the number of requests transmitted in the network. Let Q u be a quorum of the method U obtained by the function rand for each instance of the method t. Ever,y instance th has the same quorum Q u . If each instance t h issues a request U t o only a subset Quh of Q u , we can reduce the number of requests issued to the replicas of y . Here, let Q t be a set {xl, . . . x,} and Qu be { y l , . . . Y b } where a = Nt and b = Nu.Here, Qul U . . . U Qua = Q u . In order t o increase the reliability, each replica yk in Qu is required t o receive a request U from

back without performing t'. By the resolution of the redundant invocation presented here, at most one instance of a method t is surely performed on each replica even if instances on multiple replicas invoke the method t . 4.2. Quorum explosion

Let us consider the example discussed in Figure 7. Suppose Qul # Qu2, say Qul = { Y I , ~ 2 and ) Qu2 = { y 2 , y 3 ) . Here, the method U is performed on each replica in Q = Qul U Qu2 = {yl, y 2 , ' y 3 } .

The method U is performed twice on the replicas in Qul n Qu2 = { y z } as presented in the preceding subsection. If another transaction manipulates the object y by the method U , U is issued t o the replicas in the quorum Q u , say ( y 3 , y4). \ Q U I U Qu2) 2 IQu). This means that more number of replicas are locked than the quorum number Nu. Then, the instances of U on the replicas in Qul U Qua issue further requests to other replicas and

200

Figure 9: Conflicting relation.

Figure 8: Resolution of quorum explosion. more than one instance o f t . Let r ( 2 1) be a redundancy factor, i.e. the number of requests of U to be issued t o each replica yk in Qu receives. For each instance th on a replica 2h in Q t , Quh is constructed as follows ( h = 1, . . ., a ) : 1. If a 2 b-r, {yk I k = if h 5 r - b . otherwise. 2. If a < bar, Quh = { ~k I (1 1 J) L k < [ i t (1-J-1) mod b I).

[?I}

+

For example, suppose instances t l , t2, and t 3 on replicas 2 1 , 52, and 5 3 issue a request U to replicas Y I , YZ, ~ 3 and , ~ 4 i.e. , Qt = { 5 1 , 5 2 , 5 3 ) and QU = {yl, y 2 , y 3 , y4). Suppose the redundancy factor r h-1 4 is 2. Hence, Quh = {yk I(1 t (1 1) 5 k 5 h-1 4 (1 t (1 J t 1 -1) h o d 4)). Hence, Q U I = {YI, ~ 2 1 Qu2 , = { Y Z ~, 3~ ,4 1 Qu3 , ( ~ 3 :~ 4 ~ ,1 ) Two requests from the instances o f t are issued t o each replica y k . For example, suppose an instance tl on 21 is faulty. t 2 sends U t o Qu2 and t 3 sends U t o Qu3. Since Q u 2 U Qu3 = (YI, YZ, ~ 3~ ,4 1 U , is sent to every replica in Qu. If r = 1, Qul = {yl), Quz = ( ~ 2 1and , Qu3 = ( ~ 3~ ,4 ) . Thus, totally Nu requests of the method U are issued t o the replicas in Qu.Even if ( r - 1) instances out of t l , . . ., t , are faulty, the quorum number Nu replicas of y are locked and manipulated.

$1

5. Evaluation 5.1. Exchanging procedure

First, we evaluate the QB protocol in terms of messages transmitted compared with the traditional quorum-based protocol. In the traditional protocol, a transaction T issues a request, read and write, t o quorums Qr and Q w , respectively. Then, T receives responses from the replicas 2 1 , . . ., 2, in the quorum [Figure 11. If T issues a read request, T takes a value in the response with the

maximum version number. Hence, 2.Qr messages are transmitted. If T issues a write request, each replica zi sends a response with the version number b;. T takes a maximum version number bj of the replicas and then sends bj and the value t o the replicas in Q w . Hence, 3.Qw messages are transmitted. On the other hand, if T issues a request t to every replica 2; in the quorum Qt in the Q B protocol, 3.Qt messages are transmitted as shown in Figure 6. We consider an object z which supports kinds of methods t l , . . ., t l ( I 2 1). We assume every method t ; is issued in a same probability. For example, the counter object c supports inc, dec, and dsp as presented in section 3. Figure 9 shows a graph where each node shows a method and link between nodes indicates a conflicting relation. For example, inc conflicts with dsp but is compatible with inc and dec in Figure 9(1). In the traditional quorum-based protocol, inc and dec are considered t o be write and dsp is read. Figure 9(2) shows a mapping of the conflicting relation of methods t o the readlwrite conflicting one. Here, a double circle shows write and a single circle indicates read. In this evaluation, we assume a method is write if the method conflicts with itself. The quorum is decided so as t o minimize N1 . * . t N i . For example, Qinc = Qdec = 2 and Qdsp = 3 for a = 4 in the QB protocol. On the other hand, Qinc = Qdec = 3 and Qdsp = 2 in the traditional protocol. A sequence of methods is randomly generated for 1 = number of method types. For each I, possible conflicting relations are obtained. For each conflicting relation, readlwrite conflicting one is obtained as shown in Figure 9. Suppose M,, and M,, show the number of messages transmitted in traditional protocol and object-based quorum protocol, respectively. Figure 10 shows for the number of replicas ( n r ) . In this evaluation, we assume there are three types of methods, i n c , dec, and dsp and conflicting relations among the methods are obtained as shown in Figure 9. In traditional protocol, 1” replicas are locked for each request. In object-based quorum protocol, the quorum for each method is constructed with satisfying the OBQ constraint. Figure 10 shows for the

+

&

‘‘Y +

&

201

lockedi in the protocol N and Q E 3 = a 3 [ l - (1 Nas 3 ) Q L ' 2 ] replicas in the protocol Q. In the protocol R, t 2 is performed on only N2 replicas of the object, 22.

number of replicas. Here, it is shown that only 62 t o 87 percent of messages are transmitted in object-based quorum protocol.

:;I 0.4

1 ,

,

3

4

,

.

,

.

,

8

9

0.1

'2

5 6 7 Number of replicas

1 10

zo:

Figure 10: Mm,/M,,

2

3

4

6 7 Invocation ledvel (I)

8

9

Ib

(U

= 10

5.2. Redundant invocation and quorum explosion

Figure 11: Ratio of replicas to be locked and N = 3).

Next, we evaluate the QB protocol to resolve the redundant invocation and quorum explosion in terms of number of replicas locked and number of requests issued. The following three protocols R, Q, and N are considered: 1. Protocol R: without redundant invocation and quorum explosion. 2. Protocol Q: without redundant invocation. 3. Protocol N: In the protocol Q, the redundant invocation is prevented. In the protocol R, neither redundant invocation nor quorum explosion occur. The protocol R shows the QB protocol discussed in this paper . In the evaluation, we take a simple invocation model where a transaction first invokes a method tl on an object 51, then tl invokes t 2 on 52, .... Here, let a; be the number of replicas of an object xi (i = 1, 2, . . .). Let N; be the quorum number of a method ti ( N i 5 ai), where i shows a level of invocation. In the protocol, a transaction T first issues NI requests of tl to the replicas of zl. Then, each instance of tl on a replica issues N2 requests of t 2 to the replicas of 2 2 . In the protocol N , a method t 2 invoked by each instance of tl is performed. Here, totally N1-N2 requests are performed. In the protocol Q, at most one instance of t 2 is performed on each replica of 2 2 by the resolution procedure of the redundant invocation. Since the quorum explosion is not resolved, the expected number Q E 2 of replicas where t 2 is performed is a2[l - (1 Then, each instance of t 2 issues requests of t 3 to N3 replicas of 2 3 . Here, a 3 [ 1 - (1 replicas are

In the evaluation, we assume that a1 = a2 = . . . = a =: 10 and N1 = N2 = . . . = N ( 5 a). Figure 11 shows the ratios of replicas where a method is performed to the quorum number a of the replicas at each invocation level for quorum number N = 3. The dotted line with white circles shows the protocol R. The straight line indicates the protocol N and the other dotted line with black circles shows the protocol Q. If methods are invoked at a deeper level than two for N = 3, all the replicas are locked if the redundant invocation and quorum explosion are prevented. Fig;ure 12 shows the number of request messages transmitted by instances of a method t, for N = 3. A unit of the vertical axis is log(N). In the protocol N , N' request messages are issued to replicas of the object 2, because N'-' instances are performed on replicas of the object z,-~. In the protocol Q, there are a [ l - (1 - F ) Q E t - 2 ] replicas of z,-1 where instances of a method t,-l are performed. Hence, a [ l - (1 - F ) Q E a - 2 ] 1 N request messages are transmitted. In the protocol R, we assume the redundancy factor T = N in this evaluation. N 2request messages are transmitted Let; us consider a pair of methods t and U on a n object 2. According to the traditional protocols [9,10], a method is considered to be write if the object is changed by the method. Hence, if 2 is updated by t or U , Nt Nu > a. However, Nt -t N,, 5 a if t and U are compatible in the QB protocol. This means the less number of replicas are locked in the QB protocol than the traditional ones.

+

.I")%

5)N1N2]

202

*

10

Protocot N Protocol Q .eProtocol R - 0

2 9

I

r ’ i

st

r3

4

5 6 7 Invocation level (i)

8

9

Ib

Figure 12: Number of request messages ( a = 10 and N = 3).

6. Concluding Remarks This paper discussed how multiple transactions invoke methods on replicas of objects. The object supports a more abstract level of method than read and write. In addition, methods are invoked in a nested manner. It is not required t o perform every update method instance on the replica which has been performed on the other replicas if the instance is compatible with the instances performed. We discussed how t o resolve redundant invocations and quorum explosions t o occur in systems where methods are invoked on multiple replicas in a nested manner. By using the quorum-based (QB) locking protocol with the exchanging procedure and the resolution of redundant invocations and quorum explosions, an object-based system including replicas of objects can be efficiently realized.

References [I] Ahamad, M., Dasgupta, P., LeBlanc R., and Wilkes, C., “Fault FTCS Tolerant Computing in Object Based Distributed Operating Systems,” Proc. 6th IEEE S R D S , 1987, pp. 115-1 25. [2] Barrett, P. A., Hilborne, A. M., Bond, P. G., and Seaton, D. T., “The Delta-4 Extra Performance Architecture,” Proc. 20th Int’l Symp. on , 1990, pp. 481-488. [3] Bernstein, P. A., Hadzilacos, V., and Goodman, N., “Concurrency Control and Recovery in Database Systems,” Addison- Wesley, 1987. [4] Bernstein, P. A., and Goodman, N., “The Failure and Recovery Problem for Replicated Databases,” Proc. 2nd ACM POCS, 1983, pp. 114-122.

Birman, K. P. and Joseph, T. A., “Reliable Communication in the Presence of Failures,” JACM , Vol. 5, NO. 1, pp 1987, pp. 47-76. Borg, A., Baumbach, J., and Glazer, S., “A Message System Supporting Fault Tolerance,” Proc. 9th A C M Symp. on Operating Systems Principles, 1983, . 27-39. Carey, J. M. and Livny, M., “Conflict Detection Tradeoffs for Replicated Data,” ACM TODS, V01.16, No.4, 1991, pp. 703-746. Chevalier, P. -Y., “A Replicated Object Server for a Distributed Object-Oriented System,” Proc. IEEE S R D S , 1992, pp.4-11. Garcia-Molina, H. and Barbara, D., “How to Assign Votes in a Distributed System,” JACM, VOI 32, No.4, 1985, pp. 841-860. Gifford, D. K., “Weighted Voting for Replicated Data,” Proc. 7th A C M Symp. on Operating Systems Principles, 1979, pp. 150159. Hasegawa, K. and Takizawa, M., “Optimistic Concurrency Control for Replicated Objects,” Proc. of Int’l Symp. on Communications (ISCOM’97), 1997, pp. 149-152. Hasegawa, K., Higaki, H., and Takizawa, M., “Object Replication Using Version Vector,” Proc. of the 6th IEEE Int’l Conf. on Parallel and Distributed Systems (ICPADS-98), 1998, pp. 147-154. Jing, J., Bukhres, O., and Elmagarmid, A., “Distributed Lock Management for Mobile Transactions,” Proc. IEEE ICDCS- 15, 1995, pp. 118-125. Korth, H. F., “Locking Primitives in a Database System,” J A C M , Vol. 30, No. 1, 1983, pp. 55-79. Powell, D., Chereque, M., and Drackley, D., “Fault-Tolerance in Delta-4,” ACM Operating System Review, Vol. 25, No. 2, 1991, pp. 121-125. Silvano, M. and Douglas, C. S., “Constructing Reliable Distributed Communication Systems with CORBA,” IEEE Comm. Magazine, Vo1.35, No.2, 1997, pp.56-60. Tanaka, K., Hasegawa, K., and Takizawa, M., “Quorum-Based Replication in ObjectBased Systems,” Journal of Information Science and Engineering ( J I S E ) , Vol. 16, 2000, pp. 317-331.