Transaction Processing in a Mobile Computing Environment with Alternating Client Hosts *

Transcription

1 Transaction Processing in a Mobile Computing Environment with Alternating Client Hosts * Sven Buchholz, Thomas Ziegert and Alexander Schill Department of Computer Science Dresden University of Technology sb15@ibdr.inf.tu-dresden.de {ziegert,schill}@ibdr.inf.tu-dresden.de Albert Held DaimlerChrysler Research & Technology Ulm albert.held@daimlerchrysler.com Abstract Previous research in mobile data management has been focused on scenarios where mobile s replace fixed ones. However, not all potential application fields of mobile computing fit into this scenario. There exist scenarios where mobile s will not replace but accompany fixed ones. In this paper we introduce a real world application scenario requiring the capability to process a transaction from alternating, potentially mobile hosts. With this scenario in mind we have developed three approaches supporting multiple s in combination with a so called, an object in the fixed network, which manages transactions on behalf of the and the approach to realise the as a migrating object. Finally we present a prototype implementation of the most promising approach. 1. Introduction Previous research in mobile data management has been focused on the delivery of information from fixed data servers to mobile s, considering a scenario where mobile hosts replace fixed ones. There exists a number of applications which fit into this scenario, e.g. accessing a customer database by a travelling salesman. However, not all potential application fields for mobile computing correspond to this scenario. There is a large number of applications imaginable, where a mobile host does not replace but accompany the fixed host. The approach presented in this paper is based upon one of these applications. The goal of our approach is the provision of a support platform for mobile database access in the industrial pilot lot manufacturing. Nowadays a typical pattern of the engineers work looks like this: Our engineer gets notified whenever a problem arises in the manufacturing process, e.g. by phone. Now he collects related information from product and production databases on the fixed network. Therefore, he starts a distributed transaction on the workstation (a fixed host) in his office. However, the information found may not be sufficient to solve the problem. So the engineer will typically decide to move to the manufacturing site to have a close look at the problem and to have a talk with the involved workers. As a result of this he is able to solve the problem and after returning to the office adapt the information in the databases and commit the transaction. Our target is to supply this scenario with an IT support for the engineer while being mobile. Therefore, the engineer is equipped with a mobile host connected to the fixed network by wireless LAN. Thus, the future pattern of work could look like this: After being notified about a problem the engineer starts a transaction on his fixed host to retrieve information (fig. 1 (1)). When the engineer decides to move to the manufacturing site he takes his mobile host (fig. 1 (2)). At the manufacturing site, he resumes the transaction he has started on the fixed host before (fig. 1 (3)). This means he gets exactly the same mobile host 3 base station 2 fixed network database fixed host Figure 1. Resuming a transaction, started on the fixed host, on the mobile host 1 * This material is based on work supported by the BMBF under grant number 01BK604/8. The content of this material is in the responsibility of the authors

2 view of the on the mobile host which he has left on the fixed host and all future database queries within the same transaction will be submitted from the mobile host. Thus, he is able to collect additional information from the databases, find a solution in cooperation with the workers, and update the databases directly from the manufacturing site. After completing his work at the manufacturing site the engineer may decide to commit the transaction directly on the mobile host or return to the office to resume the transaction on the fixed host and eventually commit it. It is imaginable that the mobile host completely replaces the fixed one so that all processing is done from the mobile host (also in the office), even in applications like the described one. However, our approach to process a transaction from alternating hosts - a fixed one in the office and a mobile one on the move - is more convenient and the user benefits from the more powerful resources of a fixed workstation for the processing which is done in the office. 2. Requirements There are a lot of special requirements of transaction processing resulting from the presented scenario. These arise from the mobility of the hosts in general as well as from the special issues of alternating hosts. However, not all of the commonly discussed requirements due to the mobility of hosts do really apply to our scenario. In our application scenario mechanisms for disconnected operation are less important, because we assume that the mobile host will be reachable anytime in the industrial environment. So we do not consider special mechanisms for disconnected operation. Furthermore do the issues of location awareness 1 not apply to our scenario, because the mobile host is attached to the fixed network by a wireless LAN, which is considered to cover a single location. Other general requirements of transaction processing with mobile hosts are relevant in our scenario. These are: long-lived transactions Beside the problem of disconnection especially the fields where mobile computing is used may lead to a long duration of transactions. The processing of a 1 Location awareness means that the application on the mobile host is aware of the mobility of the host. Thus, a location change is not transparent to the application. Location awareness concerns the access to location dependent data and location dependent permissions as well as adoptions to the location dependent performance of remote resource access. transaction by the engineer may last up to several hours in our scenario. Certainly, long lived transactions are not a problem restricted to mobile computing. The problem has been discussed in different fields of transaction processing, e.g. workflow management or co-operative editing, e.g. Sagas [4] or Split-Transactions [8] were developed to minimise the blocking probability of resources (e.g. databases) by long-lived transactions. However, all these approaches do not realise transactions with ACID (atomicity, consistency, isolation, durability) properties. They apply weaker constraints of consistency. That is why we do not consider special mechanisms coping with long lived transactions but present an approach that handles ACID transactions. However, we assume that even transaction models with weaker constraints of consistency will work in our approach. lack of reliability of the mobile host and the wireless link It seems reasonable that concepts proved successful for distributed transaction processing in fixed networks are applicable to distributed transactions with a mobile as well as long as the remains connected. However, common weaknesses of the protocols may even get more problematic due to the potential unreliability of the mobile host as well as the wireless link. For example, the unreliability of the master process co-located with the on the mobile host or of the link between the master and the data resources as participants in a two phase commit protocol may lead to a significantly higher blocking probability of the data resources. To avoid this problem a solution for commitment control in a mobile computing environment should place the commit master process on a host in the fixed network. Beyond the general requirements of transaction processing caused by the mobility of the host there arises a special requirement from the presence of alternating hosts (this means a transaction is started on one host and later resumed on another one). Common approaches assume, that there is only one accessing data resources within a transaction. Therefore, the keeps the context information of the transaction. To satisfy this constraint while using alternating hosts, the must be realised as a mobile object, which will be able to migrate to the new host. However, this approach requires an extensive system support allowing a transparent migration of both the object and all context information

3 3. Approaches for transaction processing by alternating s supported by an agent on the fixed network To avoid the need of an extensive system support for transparent migration of both the object and all context information we suggest to discard the one- approach and introduce an approach coping with multiple s. Whenever the user wants to alter the host a new instance is created on the new host. Afterwards, this new gets the current of the transaction transferred by the old and resumes the transaction processing. The context information is not managed by the s, but by an object residing on a host in the fixed network, e.g. the engineers workstation in our application scenario. We call this instance Transaction Processing Agent (). The approach prevents the transfer of context data between host. Moreover, the can act as proxy acting on behalf of a within the fixed network. This is encouraged by the fact, that the is more reliable than a on a mobile host and allows therefore the utilisation of conventional infrastructures for database and transaction processing, which commonly not support applications with mobile nor alternating s. The has at least the following two responsibilities: 1. The routes all queries from a to the data resources. This means, that all communication takes an indirect way via the. This is also called Client-Agent-Server-Model (fig. 2). Complex queries may be decomposed in single queries to different resources by the. Afterwards, the results of the sub-queries are reassembled and the result of the complex query is passed to the. Thus, the distribution of the data resources is completely hidden from the. 2. Moreover, the manages the transaction. This includes the control of the commit protocol between the and the data resources on the fixed network. The as well as the resources participating in the commit protocol are located on the fixed network, so the may utilise an transaction service proven successful for distributed transactions without mobile participants, e.g. X/Open DTP or the CORBA transaction service. Different models of partitioning the responsibilities between the and the are conceivable: Approach 1: A without a copy of the of the transaction In this model the responsibilities of the are restricted to the above mentioned interaction with the data resources and the management of the transaction. The transaction processing is done by the agent server Figure 2. Client-Agent-Server-Model (from [6]) and therefore, the holds the of the transaction. When the host changes, it is in the s responsibility to transfer the of the transaction from the old to the new one. Consequently, a failure of the leads to a loss of the and the transaction must be rolled back. Approach 2: A that keeps the of the transaction in combination with less s In this model the whole transaction processing is the task of the. Thus, the is the only instance keeping a copy of the of the transaction. Consequently, the plays the role of a transactional. The actual on the host provides the user interface. All interactions of the user are propagated to the, that does the necessary processing and transmits the view of the new to the. Thus, this approach may result in a high amount of messages exchanged between a and the and delays in the interactivity. Approach 3: Replicated copies of the of the transaction kept by the and the This hybrid model combines the advantages of the other approaches. The transaction processing is done by the, which keeps the of the transaction. However, the holds a replica of this. Thus, a failure of the does (old) Figure 3. begin registration commit (new) Resume the transaction at the of the last - 3 -

4 not necessarily lead to a rollback because a new may resume the transaction with the s copy of the. However, the copy of the of the transaction kept by the is not updated every time the copy of the changes but only at certain points in time, so called s. This reduces the number of messages exchanged between the and the. Thus, after a failure of the a new cannot resume the transaction at the current but at the of the last (fig. 3). To avoid inconsistencies between the copy of the kept by the and the of the data within the resources (e.g. databases) the copy of the must reflect at least the results of all successful completed non-idempotent operations. Therefore, the has to transfer the current to the with any request for a non-idempotent operation. Moreover, the has to integrate the result of the operation into its copy of the. Executing idempotent operations updating the s copy of the is not mandatory but we highly recommend to use the communication between the and the, which is necessary for the operation call anyway, to transfer the in a piggyback manner to the. Hence, any operation call leads to an implicit. Moreover, the may issue s explicitly to prevent the loss of changes. 4. Comparison of the different approaches Table 1 shows a comparison of the three approaches with a as described above and the approach with a migrating from one host to another. The criteria for the comparison we have chosen are: the problem of commitment control, that may be done by the itself but only after migrating onto a fixed host or Table 1. Comparison of the different approaches one migrating approach 1 approach 2 approach 3 commitment control by the after migration onto a fixed host by the on the fixed network by the on the fixed network by the on the fixed network coping with exceptions during operation calls transaction rollback inquire the result from the (e.g. by call repetition) (exceptions caused by faults on the fixed network only then transaction rollback) inquire the result from the (e.g. by call repetition) local processing during disconnections possible (until the next data resource access) possible (until the next data resource access) impossible possible (until the next ) transfer of the of the transaction by migration direct transfer between s no need to transfer ( is kept by the ) indirect transfer between s coping with failures of the transaction rollback transaction rollback resume the transaction with a new in the current resume the transaction with a new in the saved at the last - 4 -

5 by the on the fixed network on behalf of the ; how to cope with exceptions during operation calls caused by failures of the communication link; whether or not the whole processing must be suspended during disconnections; how to transfer the of the transaction between hosts; and finally how to cope with failures of the. Because the might be situated on a potentially unreliable host, one has to assume that failures of the are frequent compared with an application on a fixed host. Therefore, an appropriate solution should allow one to resume a transaction even when a failure of the occurs. That is why the approach with one migrating as well as approach 1 is not suitable for our application scenario because the only instance keeping a copy of the of the transaction is the itself and, therefore, a failure of the implies a transaction rollback. In the other approaches at least a copy of the is kept by the on the fixed network. Because we assume failures on the fixed network and, thus, failures of the are rare, a transaction rollback is acceptable when the fails. Considering the criteria of table 1, approach 2 seems to meet our requirements. There is a little disadvantage: disconnections force the application to suspend also the local processing. But we assume disconnections as a very rare event in our target scenario, so this might be acceptable. However, there is another problem the approach inherently suffers from: every user interaction, e.g. a key press or a mouse click, causes communication to pass the event to the. Afterwards, the manipulates the corresponding to the user interaction and propagates the view of the new to the. This implies not only a high amount of messages exchanged between and, moreover any delay of the communication link directly influences the interactivity of the application (response time). It is in doubt whether or not this kind of application meets ergonomic requirements. Approach 3 is comparable with the approach with less s considering the criteria of table 1. Only the circumstance that the transaction cannot be resumed in the up-to-date but in a potentially outdated one, the one of the last, is a little drawback of this approach. However, this may be compensated by explicit s initiated by the. On the other hand, this approach allows the continuation of the local transaction processing while disconnections. The major advantage, however, is that the amount of messages is considerable less compared to the approach with a less as user interface. This results from the delayed update of the s copy of the at a. To sum up approach 3 is the most suitable one for our application scenario. Therefore, we selected this approach for the prototype implementation presented in the next section. The applicability of approach 2 depends on the efficiency of the underlying communication subsystem. In conjunction with a suitable communication subsystem this approach might be appropriate as well. 5. Prototype implementation To demonstrate the applicability of approach 3 a prototype implementation has been developed. The implementation has been realised using the Java Programming Language. We used the Java Remote Method Invocation (RMI) for the remote communication between and. Because Java RMI offers only maybe failure semantics and under the conditions of potentially long lasting disconnections, we implemented a call repetition mechanism in conjunction with duplicate elimination to ensure that every call is executed exactly once. Failures of the, however, are treated by a transaction rollback. The of the transaction is represented as a serialisable object, accumulating all data manipulated within the transaction. Due to this fact the can be transferred between and as a parameter of a remote method invocation. Figure 1 shows the basic architecture of the prototype implementation. The potentially mobile and unreliable hosts are the part of the application the user is directly interacting with. These are View and Controller forming the graphical user interface and the Client, which is the model, in the means of the Model-View-Controller design pattern. According to approach 3 presented in section 3 the Client keeps a copy of the transactions. Operations on this which can be executed locally on the host are executed by the Client. Moreover the Client initiates database access operations on the. However, the Client does not call the operations on the directly but via a proxy of the located on the host. This Proxy converts the calls of the into RMI calls on the and handles RMI exceptions by call repetition in conjunction with duplicate elimination transparently for the Client. The reliable agent host hosts the. It keeps a replicated copy of the of the transaction, converts database access calls of the into calls on the Resource Adapter, and passes the results via the Proxy back to the Client. Furthermore it integrates the results into the s copy of the. The Resource Adapter is introduced to hide the resource distribution and the access method. Moreover it is responsible for the management of distributed transactions

6 host agent host output View Proxy input Controller Client Resource Adapter Figure 4. Basic architecture of the prototype implementation database database s each assigned with a single transaction are generated by a Factory (located on the agent host but not shown in fig. 4) on demand of a application. On this occasion, an initial is created by the. Moreover, the new is registered with a directory service realised as a RMI registry. Afterwards, the may register with the and receive the initial by the. When the user wants to change the host he starts a new application on the new host. After that, the new locates the using the directory service and contacts it to get the current of the transaction. If an old is still registered with the, the asks it for the current. Implicitly, the old is deregistered (fig. 5). When the old is unreachable, after a timeout period the assumes that the old has failed and claims its copy of the as the valid one. Consequently, the s copy of the is transferred to the new (fig. 6). If a ends before it has been replaced by a new one, it explicitly deregisters itself with the. At the same time the copy of the kept by the is (old) Checkpoint s1 of work? registration (new) updated so that a new gets the current (fig. 7). To enable access control for s connecting with a the stores the proved identity of the user associated with the application that creates the. Whenever a new requests to be registered with a it presents the proved identity of its user. If the identity does not match the identity of the user that has created the the request is rejected. Due to this mechanism the security gap in this approach is closed. Within the prototype implementation no databases managed by DBMS systems are used as data resources. Instead, we simulate the resource access by objects in the environment of the Resource Adapter. Moreover, these resource objects do not implement mechanisms to make any persistent changes of the data. Protocol mechanisms for commitment control are realised by the Resource Adapter itself. However, the implementation is open to integrate a transaction service conforming to the CORBA transaction service specification with minor adoptions. (old) Checkpoint s1 of work? registration (new) deregistration s2 s2 timeout s1 Figure 5. The old is active when it is replaced Figure 6. The old is unreachable when it is replaced - 6 -

7 (old) s1 deregistration s2 registration 6. Related Research To our knowledge previous research has not addressed the problem of transaction processing from alternating, potentially mobile hosts. However, transaction processing from mobile hosts has been discussed by several research papers. Different papers have investigated new transaction models with adopted, possibly weaker constraints of consistency than ACID to cope with disconnections. For instance, this approach used by the clustering model [7] with weak and strict transactions or Reporting and Co- Transactions [1] for structuring workflow transactions. Another approach followed up by [10] is to incorporate the semantics of the data to allow consistent 2, concurrent access even in case of disconnected operation. Mobility behaviour is captured by the Kangaroo Transaction Model ([2]). Similar to our approach all data resources are accessed through an instance on the fixed network (typically on the base station), the Data Access Agent (DAA), that performs the transaction management. However, the Kangaroo model enhances this idea by moving the management of the transaction from one DAA to another one as the mobile host moves. Hence, the communication between the and the DAA is kept local even when the mobile host moves. Due to the fact that the Kangaroo model assumes a multidatabase approach with autonomous underlying DBMS systems, which allow subtransactions to commit independently, Kangaroo Transactions do not have ACID properties. Another work discussing the approach to have an instance on the fixed network, a so called user agent, acting on behalf of the on the mobile host can be found in [9]. This paper considers how the user agent migrates on the network. Our approach does not consider the migration of the agent or of the transaction management, as in the Kangaroo Transaction Model. However, it is conceivable 2 ACID properties can be maintained. s2 (new) Figure 7: The old is shut down before it is replaced to extend the by the mobility feature. Unlike the Kangaroo Transaction approach, that assigns one DAA with one base station or one network domain, and the user agent approach of [9], that assigns one user agent with one mobile host, our approach assigns one with one transaction. 7. Summary In this paper we have investigated transaction processing from alternating, potentially mobile hosts to allow mobile hosts to accompany instead of to replace fixed ones as hosts for the purpose of transaction processing. Proceeding from a real world application scenario we have developed three different approaches applying multiple s in conjunction with an instance on the fixed network, the, managing the transaction on behalf of the. Furthermore we have compared them with the idea to realise the as a migrating object. The most promising approach: having both the and the keeping a replicated copy of the of the transaction has proven successful in a prototype implementation. 8. References [1] P. K. Chrysanthis: Transaction Processing in Mobile Computing Environment; Proc. of IEEE Workshop on Advances in Parallel and Distributed Systems, pp.77-82, October 1993 [2] M. H. Dunham, A. Helal, S. Balakrishnan: A mobile transaction Model that captures both the data and movement behavior; ACM/Baltzer Journal on Special Topics in Mobile Networks and Applications, Vol 2, pp , 1997 [3] Margaret H. Dunham, Abdelsalam (Sumi) Helal: Mobile Computing and Databases: Anything new?; SIGMOD Record, Vol 24, No. 4, pp.5-9, 1995 [4] H. Garcia-Molina, K. Salem: Sagas; Proc. Of the ACM SIGMOD International Conference on Management of Data, pp , May 1987 [5] Q. Lu, M. Satyanarayanan: Isolation-Only Transactions for Mobile Computing; Operating Systems Review, Vol 28, No. 2, pp.81-87, 1994 [6] Oracle Mobile Agents White Paper; [7] E. Pitoura. B. Bhargava: Maintaining Consistency of Data in Mobile Distributed Environments; Proc. of the 15 th International Conference on Distributed Computing Systems, pp , 1995 [8] C. Pu, G. E. Kaiser: Split-Transactions for Open-Ended Activities; Proc. of the 14 th International Conference on Very Large Data Bases, pp.26-36,

8 [9] R.Ramjee, T. F. La Porta, M. Veeraragahvan: The use of network-based migrating user agents for personal communication services; IEEE Personal Communications, pp.62-68, December 1995 [10] G. Walborn, P. Chrysanthis: Supporting Semantic-Based Transaction Processing in Mobile Database Applications; Proc. of the 14 th IEEE Symposium on Reliable Distributed Systems, pp.31-40,1995 [10] Java TM Remote Method Invocation Specification; Sun Microsystems Inc