Fault-tolerant mobile agents in distributed objects ... - Semantic Scholar

Fault-Tolerant Mobile Agents in Distributed Objects Systems Masashi Shiraishi, Tomoya Enokido, and Makoto Takizawa Dept. of Computers and Systems Engineering Tokyo Denki University, Japan {shira, eno, taki}@takilab.k.dendai.ac.jp Abstract

multiple object servers are required to be atomically manipulated by a transaction. In the traditional systems, objects are locked and transactions are timestamped [6] to serialize multiple transactions. In addition to supporting the serializability, the atomic manipulation of multiple object servers has to be supported. The two-phase commitment protocol [6, 8] is widely used to realize the atomic manipulation of multiple database systems. The two-phase commitment protocol supports robustness against server faults but not against application faults, i.e. servers may block due to client faults [13]. For example, if programs are replicated, the servers can be committed as long as some replica is operational.

A transactional agent is a mobile agent which manipulates objects in one or more than one object server so as to satisfy some constraints. There are some types of constraints depending on applications. ACID is one of the constraints, which shows traditional atomic transactions. There are other constraints like at-least-one constraint where a transaction can commit if at least one object server is successfully manipulated. An agent leaves a surrogate agent on an object server on leaving the object server. A surrogate holds objects manipulated by the agent and recreates an agent if the agent is faulty. In addition, an agent is replicated by itself. Thus, transactional agents are fault-tolerant. We discuss how transactional agents with types of commitment constraints can commit. We discuss how to implement transactional agents.

Mobile agents [1] locally manipulate objects on object servers by moving to the object servers. An agent first moves to an object server where objects are manipulated. After manipulating all or some object servers, an agent makes a decision on commit or abort. For example, an agent commits only if all the object servers are successfully manipulated. Thus, each agent has its own commitment condition like atomic commitment. A general concept of transactional agent is discussed by Nagi [10]. In this paper, a transactional agent is defined to be a mobile agent which manipulate one or more than one object server with some type of commitment constraint and isolation level. In addition, an agent negotiates with another agent if the agent manipulates objects in a conflicting manner. Through the negotiation, each agent autonomously makes a decision on whether the agent continues to hold the objects or gives up to hold the objects. A transactional agent autonomously finds another object server if an object server where the agent to move is faulty. An agent leaves its surrogate agent which holds locks on objects in an object server when the agent leaves the object server. The surrogate agent holds locks on objects until the agent commits or aborts. The agent is faulty due to the fault of a current object server. Some surrogate agent of the agent recreates another incarnation of the agent. Furthermore, an agent can be replicated to realize parallel and fault-tolerant computation. Each replica of the agent is au-

1. Introduction In traditional client-server applications, application programs and objects exist in clients and servers, respectively. On the other hand, any computer can have programs and objects in peer-to-peer (P2P) applications. In addition, huge number and various types of computers are interconnected in networks and computers are not so reliable as server computers. For example, in order to reduce the battery consumption and due to communication noise, connections with mobile computers are often disconnected. Thus, application programs are required to be performed in lessreliable computers and networks. If programs exist on servers, the programs can be more reliably performed even if mobile computers are disconnected. If application programs are performed on multiple computers, the applications can be reliably performed even on less-reliable computers. In database applications, transactions manipulate objects so as to satisfy ACID (atomicity, consistency, isolation, and durability) properties [6, 9, 10]. For example, objects in 1

Proceedings of the The Ninth IEEE Workshop on Future Trends of Distributed Computing Systems (FTDCS’03) 0-7695-1910-5/03 $17.00 © 2003 IEEE

tonomously performed. Even if some replica agent is faulty, the agent is operational as long as at least one replica is operational. We discuss how transactional agents manipulate objects in multiple object servers in presence of server and application faults. In section 2, we present a system model. In section 3, we discuss transactional agents. In section 4, we discuss how to implement transactional agents by using database servers. In section 5, the transactional agent are evaluated compared with traditional client-server applications.

Each object server supports an agent with an isolation level which shows when the agent releases objects. For example, if an agent releases an object before holding another object, dirty read occurs. In the strict two-phase locking protocol [6], neither dirty read nor cascading abort occur since all the locks are not released before commit or abort.

2.2. Mobile agents An agent is a program which can be autonomously performed on multiple object servers. A home computer of an agent is one where the agent is initiated. A current server of an agent is one where the agent exists. An agent issues methods to an object server to manipulate objects in the current object server. Every object server is assumed to support a platform to perform agents. First, an agent A is autonomously initiated on an object server. Suppose an agent A lands at an object server Di to manipulate an account object through a method increment. Here, suppose another agent B is resetting the account object. Since a method reset conflicts with a method increment, the agent A cannot be started. A pair of agents A1 and A2 are referred to as conflict if the agents A1 and A2 manipulate a same object through conflicting methods. After landing at an object server Dj , the agent A is allowed to be performed on the object server Dj if there is no agent on an object server Dj which conflicts with an agent A. An agent A can be replicated in multiple replicas A1 , . . . , Am (m ≥ 2). Each replica Ai is autonomously performed. By replicating an agent, parallel processing and fault-tolerant computings of the agent can be realized. Even if some replica is faulty, other replicas of the agent can be performed. In addition, replicas are in parallel performed on object servers. An agent autonomously finds a destination object server to which the agent moves. If the destination object server is faulty, the agent finds another destination object server. As long as an agent is operational, the agent can try to find another destination object server even if a destination object server is faulty. An agent is not faulty by escaping faulty servers.

2. System Model 2.1. Object servers A system is composed of object servers D1 , . . ., Dm (m ≥ 1), which are interconnected with reliable, high-speed communication networks. Each object server supports a collection of objects and methods for manipulating the objects. Each object server supports following methods to manipulate objects in the server: 1. begin-trans: A subtransaction starts with some isolation level [5]. Methods issued by the subtransaction are recorded in the log. 2. op(o): A method op is performed on an object o. 3. prepare: The log of a subtransaction is saved in a stable memory. 4. commit: Objects are physically updated by using the log and a subtransaction commits. 5. abort: A subtransaction aborts, i.e. objects are not updated. If result obtained by performing a pair of methods op1 and op2 on an object depends on a computation order of op1 and op2 , op1 and op2 are referred to as conflict on the object. For example, a pair of methods increment and reset conflict on a counter object. On the other hand, increment and decrement do not conflict, i.e. are compatible. If a method op1 from a transaction T1 is performed before a method op2 from another transaction T2 and the methods op1 and op2 conflict, every method op3 from T1 is required to be performed before every method op4 from T2 conflicting with the method op3 . This is a serializability property [6, 7]. There are locking protocols [6–8] and timestamp ordering protocols [6] to realize the serializability. The two-phase commitment protocol [6] is widely used to realize the atomic manipulation of objects in multiple object servers. First, prepare is issued to all the object servers. If all the servers are prepared, commit is issued to them. The commitment protocol is robust for fault of object server. However, if the application server is faulty, all the operational object servers might block [6, 13].

3. Transactional Agents 3.1. Commitment conditions A transactional agent A manipulates objects in multiple object servers by moving around the object servers. A scope Scp(A) of an agent A means a set of object servers which the agent A possibly to manipulate. If an agent A finishes manipulating each object server Di , the commitment condition Com(A) of the agent A is checked. There are following commitment conditions: 2


commitment condition Com(A) on the surrogates A1 , . . ., Am is satisfied, the agent A commits. For example, an agent commits if all the surrogates in the history H(A) safely exist in the atomic commitment condition. If all the servers in the set H(A) are manipulated but the commitment condition Com(A) is not satisfied, the agent A aborts. Then, the surrogate agents of the agent A are annihilated.

[Commitment conditions] 1. Atomic commitment: an agent is successfully performed on all the object servers, i.e. all-or-nothing principle. This is a commitment condition used in the traditional commitment protocols [7, 13]. 2. M ajority commitment: an agent is successfully performed on more than half of the object servers. 3. At-least-one commitment: an agent is successfully performed on at least one object server. 4. nr commitment: an agent is successfully performed on more than r out of n object servers (r ≤ n). 5. General commitment: some condition is satisfied for the object servers.

A A1

Ai

D1

The atomic, majority, and at-least-one con commitment n , and n1 ditions are shown in forms of nn , (n+1)/2 commitment conditions, respectively. Generalized consensus conditions with preference are discussed in a paper [12]. A commitment condition Com(A) is specified for each agent A by an application. There are still discussions on when the commitment condition Com(A) of an agent A can be checked while the agent A is moving around object servers. Let H(A) be a history of an agent A, i.e. set of object servers which an agent A has so far manipulated (H(A) ⊆ Scp(A)). The scope Scp(A) can be partially ordered according to the preference →. For a pair of object servers Di and Dj , “Di → Dj ” means that an agent prefers Di to Dj . The agent A visits the object server Di before Dj if A could visit both Di and Dj . The atomic commitment condition Com(A) can hold only if all the object servers to be manipulated are successfully manipulated, i.e. H(A) = Scp(A). On the other hand, the commitment condition Com(A) can hold only if at least one object server is successfully manipulated, i.e. |H(A)| = 1 in the at-least-one commitment condition.

Di

Am

Dm

: surrogate agent of A

Figure 1. Surrogate agents. As discussed here, a surrogate may be aborted in the negotiation with other agents or due to the fault of the object server. There are two states of each surrogate Bj , abortable and committable. If the surrogate Bj is abortable, Bj can be aborted. For example, if another agent A takes over the surrogate Bj through the negotiation between A and Bj , the surrogate Bj aborts. After manipulating object servers, the agent B of the surrogate Bj tries to commit if the commitment condition Com(A) is satisfied. The agent B sends a prepare message to all the object servers in the set H(A). On receipt of the prepare message, the surrogate Bi enters committable state where update data is saved in a log. Here, the surrogate Bj cannot abort in the negotiation. That is, other agents cannot take over Bj . prepare /

abortable

If an agent A leaves an object server Di , an agent named surrogate of A is left on Di [Figure 1]. The surrogate agent Ai still holds objects in the object server Di which are manipulated by the agent A on behalf of the agent A. A surrogate agent releases objects depending on the isolation level of the agent A. The surrogate releases objects until the agent A commits or aborts at the highest isolation level, i.e. strict level. The surrogate releases objects just after leaves at the weakest isolation level.

commitable commit / committed

to / negotiation //

abort /

aborted

Figure 2. States of surrogate.

3.2. Resolution of confliction

Suppose another agent B arrives at an object server Dj after the agent A leaves the object server Dj . Here, the agent B negotiates with the surrogate agent Ai of the agent A if the agent B conflicts with the agent A. After the negotiation, the agent B might take over the surrogate Ai . Thus, when the agent A finishes visiting all the object servers, some surrogate may not exist due to the fault and abortion in negotiation with other agents. The agent A starts the negotiation procedure with its surrogates A1 , . . ., Am . If a

Suppose an agent A moves to an object server Dj from another object server Di . An agent A cannot be performed on an object server Dj if there is an agent or surrogate B conflicting with A. Here, the agent A can take one of the following ways: 1. The agent A in the object server Di waits until the agent A can land at an object server Dj . 3


2. The agent A finds another object server Dk which has objects to be possibly manipulated before the object server Dj . 3. The agent A negotiates with the agent B in the object server Dj . 4. The agent A aborts.

: move : retreat

Suppose there are other agents B1 , . . ., Bk on the object server Dj . Here, each “agent Bi ” shows an agent which are being performed or surrogate agent of an agent. If the agent A conflicts with some agent Bj on an object o, the agent A negotiates with the agent Bj with respect to which agent A or Bj holds the object o [Figure 3]. There are following negotiation policies:

Ak

Dk

A1

Aj

A1

Aj

D1

Dj

Dj+1

Di

Figure 4. Retreat. with the agent Bj on the object server Dj . Here, there are two approaches to Bj ’s releasing the object o:

Bj

a. The agent Bj aborts if the agent A precedes the agent Bj , e.g. the priority of the agent A is higher than the agent B. b. The agent Bj rolls back to its checkpoint most recently taken and then restarts if the agent A precedes the agent Bj .

A o Dj

If the agent Bj agrees with the agent A in the negotiation protocol, the agent A can manipulate objects by taking over the agent Bj . Here, the agent Bj not only releases the object but also aborts. Each agent autonomously makes a decision on which way to be taken through negotiation with other conflicting agents.

Figure 3. Conflicting agents. [Negotiation policies] 1. The agent A blocks until the agent Bj commits. 2. The agent A takes over the agent Bj . That is, after the agent Bj releases objects and blocks, the agent A starts. 3. The agent Bj aborts and the agent A starts. The first way is similar to the locking protocol. An agent A blocks if some agent B holds an object o in a conflicting way with the agent A. If the agent B waits for release of an object held by the agent A, a pair of the agents A and B are deadlocked. Thus, deadlock among agents may occur. If the timer expires, the agent A takes a following way:

3.3. Commitment There are two types of agents, ordered agents and unordered agents. Every pair of ordered agents manipulate objects in a well-defined way. Each ordered agent A is assigned a precedent identifier pid(A). An agent A1 precedes another agent A2 (A1 → A2 ) iff pid(A1 ) < pid(A2 ). For example, timestamp [6] can be used as an identifier of an agent. That is, the identifier pid(A) of an agent A is time ts(A) when the agent A is initiated at the home server. An agent A1 precedes another agent A2 only if ts(A1 ) < ts(A2 ). An agent A1 is concurrent with another agent A2 (A1 || A2 ) iff neither A1 precedes A2 nor A2 precedes A1 . Here, the agents A1 and A2 can be performed on an object server in any order. If a pair of the agents As and At conflict on object servers Di and Dj , the agents As and At are required to be performed in the precedence order at the object servers Di and Dj . There never occurs deadlock. Like locking protocols, an unordered agent can obtain an object if no conflicting agent obtains the object. An agent Bj means an “agent” or a “surrogate agent” in an object server Dj . An agent A would like to be performed on an object server Dj but conflicts with some agent Bj in Dj . First, suppose an agent Bj is a surrogate of an agent

1. The agent A retreats to an object server Dj in the history set H(A), i.e. object server which A has passed over. The surrogates of the agent A which have been performed before the object server Dj are aborted. 2. The surrogate Aj on Dj recreates a new incarnation A. The agent A finds another destination object server Dh [Figure 4]. The surrogate Aj to which the agent A retreats plays a role of checkpoint of A. Differently from traditional checkpointing [11], the agent A retreating to some surrogate Aj autonomously finds an object server which may be different from one which A has visited. Next, an agent A tries to take over an agent Bj in an object server Dj if the agent B holds an object and the agent A conflicts with Bj . Here, the agent A starts the negotiation 4


B. The surrogate agent Bj makes a following decision depending on the commitment conditions:

have to be transferred to D2 . Thus, it is an important decision factor to decide a route from the performance point of view whether an object server supports JDBC classes or not.

1. At-least-one commitment: If the surrogate Bj knows at least one surrogate of the agent B is committable, the surrogate Bj releases the object and aborts. The surrogate Bj informs the other surrogates of this abort. 2. Majority commitment: If the surrogate Bj knows more than half of the surrogates of B are committable, the surrogate Bj releases the object and aborts. The surrogate Bj informs the other surrogates of this abort. 3. nr commitment: If the surrogate Bj knows more than r surrogate agents of the agent B are committable, the surrogate Bj releases the object and aborts.

home

: JDBC

server

: agent : server : movement : load : home computer

4. Implementation 4.1. Environment

Figure 5. Agent and JDBC.

A transactional agent is implemented in Aglets [1]. Relational database systems Sybase [3] and Oracle8i [4] on types of platforms Solaris, Linux, and Windows2000 are used as object servers which are interconnected with a 100base Ethernet. Each object server supports an XA interface [14] for doing the two-phase commitment [6, 8]. An agent manipulates table objects in object servers by issuing SQL [5] commands, select and update. A mobile agent realized in Telescript can carry the state to other object servers, i.e. process of agent can be migrated. However, an Aglets agent cannot bring the state to other object servers, just text and heap area are transferred. An object server is realized in an Oracle or Sybase object server. JDBC (Java database connectivity) [2] is used to realize a program interface to an object server. JDBC classes are required to be loaded to an Aglets agent in order for the agent to issue SQL commands on an object server. A home computer of an agent means a computer where the agent is initiated. In order to perform an agent on an object server, JDBC classes required to exist on the home computer or the object server. If JDBC does not exist on the object server, JDBC classes on the home computer are transfered to the object server. It takes about 10 seconds to transfer and load JDBC class in the 100base Ethernet. In the Internet, it takes about 30 to 40 seconds to transfer JDBC classes. Each type of object server, i.e. Oracle and Sybase, requires an agent to use its own type of JDBC. Hence, an agent cannot move to an object server if neither the object server nor the home computer support JDBC for the type of the object server. Next, suppose the home computer supports JDBC classes. An agent moves to one of object servers D1 and D2 . Here, suppose one server D1 has JDBC classes but the other object server D2 does not. It takes the agent a longer time to move to the object server D2 than D1 because JDBC classes

4.2. Surrogates As presented before, after an agent leaves an object server, a surrogate agent of the agent stays on the object server while the surrogate agent holds objects manipulated by the agent. The surrogate agent releases the objects on time when the agent commits or aborts. Here, suppose an agent manipulates objects in an object sever Di by issuing SQL commands with some isolation level and commitment condition. In this implementation, an agent and its surrogates are realized as follows [Figure 6]: 1. An agent A manipulates objects in an object server Di . 2. A clone A of the agent A is created if the agent A finishes manipulating objects in an object server Di . The clone A leaves the object server Di for another object server Dj as an agent. The agent A stays on Di as the surrogate. Thus, a clone of an agent A is created on a current object server and moves to another object server as an agent A while the agent A stays on the current object server as a surrogate. The agent A is just performed on the object server Di and then is changed to the surrogate. If an agent leaves the object server Di , locks on objects held by the agent are released. Therefore, an agent stays on an object server Di and a clone of the agent leaves the object server Di for another object server Dj . If all the object servers required by the commitment condition are successfully manipulated, an agent makes a decision on commit or abort by communicating with the surrogates as discussed in this paper. If commit is decided by the commitment condition, a surrogate commits on an object server Di . Otherwise, a surrogate aborts. 5


agent A

:clone clone

Aj

Ak :surrogate

Ai

Aj

Ai prepare

: abort

Ak aborted

Di

Dj

Aj

: commit

prepared

commit

Dk

time

Figure 6. Creation of surrogate.

Figure 8. Conditional commitment.

4.3. Commitment surrogate Ai asks the other surrogate if they had committed. Suppose the surrogate Ai is faulty before receiving prepared. Here, Ai is abortable. If the surrogate Ai is recovered, Ai unilaterly aborts.

An agent A can commit if all or some of the surrogates commit depending on the commitment condition Com(A). Each agent is also realized by using the XA interface [14] which supports the two-phase commitment protocol. Each surrogate issues a prepare request to a server on receipt of a prepare message from the agent. If prepare is successfully performed, the surrogate sends a prepared message to the agent. Here, the surrogate is referred to as committable. Otherwise, the surrogate aborts after sending aborted to the agent. The agent receives responses from the agents after sending prepare to the surrogates. On receipt of the responses from surrogates, the agent makes a decision on commit or abort based on the commitment condition. In the atomic condition, the agent sends commit only if prepared is received from every surrogate. The agent sends abort to all committable servers if aborted is received from at least one surrogate. On receipt of abort, a committable surrogate aborts. In the at-least-one commitment condition, the agent sends commit to all committable servers only if prepared is received from at least one object server. Ai

5. Evaluation We evaluate transactional agents in terms of access time compared with client-server model. In the evaluation, three object servers D1 , D2 , and D3 are realized in Oracle which are in Sun workstation (SPARC 900MHz x 2) and a pair of Windows PCs (Pentium3 1.0GHz x 2 and Pentium3 500MHz), respectively. The object servers are interconnected with 100base LAN. JDBC classes are already loaded in each object server. An application program A manipulates table objects by issuing select and update to some number of object servers at the highest isolation level, i.e. select for update in Oracle. The program is implemented in Java for Aglets and a client-server model. In the client-server model, the application program A is realized in Java on a client computer. In the transactional agent model, the application A is realized in Aglets. The computation of Aglets is composed of moving, class loading, manipulation of objects, creation of clone, and commitment steps. In the client-server model, there are computation steps of program initialization, class loading to client, manipulation of objects, and two-phase commitment. Figure 9 shows how long it takes to perform each step for two cases, one for manipulating one object server and another for manipulating two object servers, in client-server (CS) and transactional agent (TA) models. In the transactional agent model, Aglets classes are loaded to each object server before an agent is performed. Since Java classes are loaded to only client in the client-server model, the time for loading the classes is constant for any number of object servers. As shown in Figure 9, time to manipulate objects in a transactional agent is shorter than the client-server model because there is no communication between agent

: agent XA JDBC

: server

Di

Figure 7. XA interface. Next, we discuss how to support robustness against agent faults. Suppose a surrogate Ai of an agent A is faulty after sending prepared. Here, the surrogate is committable. On recovery of the committable surrogate, the surrogate unilaterly commits if the surrogate is committable in the atleast-one transaction condition. In the atomic condition, the 6


6. Concluding Remarks

and object server. The time to load Aglets classes in each object server is about half of the total computation time in the transactional agent. The transactional agent faster manipulates objects than the client-server model. On the other hand, Aglets classes have to be loaded in the transactional agent. It takes about two seconds to load Aglets classes. Next, access time from time when the application program starts to time when the application program ends, is measured for Agents and client-server model. Figure 10 shows the access time for number of object servers. The non-cache Aglets shows that Aglets classes are not loaded when an agent A arrives at an object server. Here, the agent can be performed after Aglets classes are loaded. On the other hand, the cache Aglets means that an agent manipulates objects in each object server where Aglets classes are already loaded, i.e. the agent comes to the object server after other agents have visited on the object server. As shown in Figure 10, the client-server model is faster than the transactional agent. However, the transactional agent is faster than the client-server model if object servers are frequently manipulated, i.e. cashed Aglets classes are a priori loaded.

This paper discussed a mobile agent model for processing transactions which manipulate multiple object servers. An agent first moves to an object server and then manipulates objects. The agent autonomously moves around the object servers. If the agent conflicts with other agents in an object server, the agent negotiates with the other agents. The negotiation is done based on the commitment condi tions, i.e. all-or-nothing, at-least-one, majority, and nr conditions, and types of agents, i.e. ordered and unordered ones. We showed the evaluation of the mobile agent-based transaction systems for applications. If Aglets classes are a priori loaded, the transactional agents can manipulate object servers faster than the client-server model.

References [1] Aglets software development kit home. http://www.trl.ibm.com/aglets/. [2] Jdbc data access api. http://java.sun.com/products/jdbc/. [3] Sybase sql server. http://www.sybase.com/. [4] Oracle8i concepts vol. 1. Oracle Corporation, 1999. Release 8.1.5. [5] American National Standards Institute. Database language sql, 1986. [6] P. A. Bernstein, V. Hadzilacos, and N. Goodman. Concurrency control and recovery in database systems. In Addison Wesley, 1987. [7] J. Gray and A. Reuter. Transaction processing : Concepts and techniques, Morgan kaufmann, 1993. [8] F. H. Korth. Locking primitives in a database system. Journal of ACM, 30(1):55–79, 1989. [9] N. A. Lynch, M. Merritt, W. Weihl, A. Fekete, and R. R. Yager. Atomic transactions, 1994. [10] K. Nagi. Transactional agents : Towards a robust multiagent system, 2001. Lecture Notes in Computer Science, Springer-Verlag, No.2249. [11] R. S. Pamula and P. K. Srimani. Checkpointing strategies for database systems. In Proceedings of the 15th annual conference on Computer Science, pages 88–97, 1987. [12] I. Shimojo, T. Tachikawa, and M. Takizawa. M-ary commitment protocol with partially ordered domain. Proc. of the 8th Int’l Conf. on Database and Expert Systems Applications(DEXA’97), pages 397–408, 1997. [13] D. Skeen. Nonblocking commitment protocols. Proc. of ACM SIGMOD, pages 133–147, 1982. [14] X/Open Company Ltd. X/open cae specification distributed transaction processing: The xa specification., 1991. Document number XO/CAE/91/300.

6

access time [sec.]

5

2PC DB manipulation class loading move creation of clone program initialization

4 3 2 1 0

Aglets * Aglets **

CS *

CS **

* : one object server ** : two object servers

access time [sec.]

Figure 9. Access time.

11 10 9 8 7 6 5 4 3 2 1 0

Client server Aglets (non-cache) Aglets (cache)

1

2

3

number of object servers

Figure 10. Client server vs. agent.

7
