Supporting Cache Coherence in Mobile Cooperative Systems - WWW2
Seventh IEEE International Symposium on Network Computing and Applications
Supporting Cache Coherence in Mobile Cooperative Systems Carla Diacui Medeiros Berkenbrock, Celso Massaki Hirata Instituto Tecnol´ogico de Aeron´autica - ITA Department of Computer Science S.J.Campos, SP, Brazil {diacui, hirata}@ita.br
Abstract
bile computing is energy consumption. Mobile users are frequently disconnected from the network or kept in weak connection status to save energy. In addition, the bandwidth of the wireless channel is also limited. Copies of data can be kept in mobile devices to reduce data retrievals from the server. Then, caching data reduces the uplink and downlink bandwidth consumption as well as the average latency in data access. It is also important to consider that wireless communication is one of the major sources of energy consumption that reduces battery life of mobile devices. An important concept in the CSCW area is awareness. Awareness is a feeling of illusion through which participants in a cooperative system can sense the presence of others and their movements by sharing a workspace. Maintaining awareness of the users working context is crucial to successful cooperation. However, considering that mobile users work under resource constraints the information delivered to a mobile device should be restricted to the one that is relevant for the users work. In this paper, we propose a cache coherence scheme for mobile cooperative work. This scheme is based on periodic broadcast of invalidation reports and provides some aspects of awareness information. In addition, we developed a prototype application in order to demonstrate the feasibility of proposed scheme. Our study distinguishes from others in three ways: First, our scheme avoids invalidation cached data by the use of vulnerable locks. Second, the scheme focuses on providing cooperation using the scheme to present awareness information. Third, different from other studies that are only based on simulation models, we demonstrate that our scheme is feasible under a real environment.
Efficient cache coherence strategies are critical to maintain data consistency and provide a reasonable performance of wireless applications with mobile devices. However, the majority of the current strategies for cache coherence in mobile environments have not been designed to be used in cooperative applications. In this paper we propose and describe an implementation of a cache coherence scheme for mobile cooperative work. The scheme is based on periodic broadcast of invalidation reports and provides some aspects of awareness information. The implementation is made through the development of a prototype cooperative application.
1. Introduction Computer-Supported Cooperative Work (CSCW) is a research area that provides both an understanding of how people work together and how systems can be successfully designed to accommodate these work practices. The advance of mobile computing and the new ways of connectivity allow the integration of mobile devices in cooperative applications. Maintaining data consistency is a challenge in building mobile systems because mobile users usually communicate using loose coupled systems and their devices are often disconnected, thus they neither can access the server nor are accessible by other devices all the time. Therefore mobile applications have to allow for such disconnections. Caching data is an interesting strategy to improve the interactive response time, reduce latency, save bandwidth, maintain data consistency, and improve performance in wireless environments. However, considering that mobile units (MUs) can suffer from disconnections and changes of one piece of information on simultaneous form, the usage of mechanism to provide coherence is required. The mechanism must assure that the data caching in MUs are coherent with the stored data in the server. Other key issue for mo-
978-0-7695-3192-2/08 $25.00 © 2008 IEEE DOI 10.1109/NCA.2008.11
2
Related Work
Barbara and Imieliski [2] propose three new cache invalidation strategies that use invalidation reports and a stateless server: Broadcasting Timestamp (TS), Amnesic Terminals (AT), and Signatures (SIG). Wang et al [7] propose a strategy called Scalable Asynchronous Cache Con-
240
sistency Scheme (SACCS), that provides a weak cache consistency, and inherits features of both stateless and stateful approaches. Madhukar and Alhajj [4] present a cache coherence scheme for the wireless mobile environment called Adaptive Energy Efficient Cache Invalidation Scheme (AEECIS), which uses a stateful server and it is adaptive because it changes the data dissemination strategy based on the current conditions. Other work investigates the awareness in mobile environments. Cheverst et al [3] examine the need for a new type of awareness that provides group members with relevant information concerning the effect that the constraints imposed by mobile environment might have on the group’s collaboration. Pinelle and Gutwin [6] discuss the preference that users have for low-cost collaboration such as lowlevel awareness information and asynchronous communication. Papadopoulos [5] investigates opportunities for improving awareness in mobile environments with a view to enable collaboration under power constraints and transitory network disconnections. To the best of our knowledge, we have not found any other work on cache coherence in mobile cooperative applications using blocking protocol and presenting aspects of awareness information. As mentioned, the previous work related to cache coherence has investigated the mobile constraints without considering the requirements of cooperative systems. Therefore strategies for cache coherence in mobile environments which consider energy saving, communication delay, disconnection, for cooperative applications are required. In addition, current cache coherency schemes have not been designed to provide awareness information. We believe that the use of cache coherence mechanisms can facilitate the maintenance of some awareness aspects. For example, the messages exchanged between a mobile user and the server to keep cache coherence can also be used to supply information about both user’s context and activities.
3
ence allow executing operations in a nonblocking manner [2, 4, 7]. Nonblocking protocols are lighter and generally provide better performance for applications where clients are independent from each other. On the other hand, the blocking protocol maintains consistency by preventing actions from users who are not holding the lock. Only operations from the current lock holder are allowed to make state changes to the shared data. As mentioned, in general, nonblocking protocols can achieve better response time than blocking protocols. However, in case of inconsistencies, nonblocking protocols should be able to restore states. The effects of the undo operations in the restoration affect both the system performance and the awareness. Additionally, in order to perform undo operations in mobile cooperative environments consistently, it is required to take into account the frequent MUs disconnections. CCS-MoCW uses blocking protocol to allow that operations be realized so that their effect on shared data can be serially equivalent. Additionally, we use timeouts to detect disconnections and avoid that a disconnected MU holding a lock can lead to deadlock. The server broadcasts an IR every bI seconds. When the MU receives an IR, it returns an “ack” message to server. The server receives the “ack” messages, then it reports which MUs are disconnected. If the MU remains disconnected for longer than a maximum disconnection period (P) its lock becomes vulnerable. If any other MU wants to access a vulnerable lock, the server releases the vulnerable lock and the lock is granted to the other MU. When an MU enters in the cooperative group, it receives a timestamp from server. The timestamp is used to monitor the MUs’ cache and to verify if the version of its cache is coherent with the data in the server. The MU timestamp is always assigned by the server. So we do not have the problem of generating different timestamps. Thereafter, the MU can request access to an object for updating. To each record in the cooperative group it is assigned a unique record identifier (id). When the server receives a lock message for an id, it verifies if no other MU is holding a lock for this id or if there is a vulnerable lock for this id. In both cases, the lock is granted and the server verifies if the requested data item was changed after the last sent message of IR information. In case of change, the server sends the last version data to MU. So there is no way the MU can overwrite and invalidate information already committed. The commit message is used to insert, delete or modify data. Before modifying or deleting an item, it is necessary to hold the lock for the correspondent id. When the server receives a commit message for an id, it compares the MU timestamp with the server timestamp. If the MU timestamp is equal to the server timestamp, it means that the MU data is coherent with the server’s data. Then, the server stores the updates in the history of updates (h) and releases the lock. If the MU timestamp is smaller than the server timestamp, it checks
Cache Coherence Scheme for Mobile Cooperative Work
In this section, we propose a Cache Coherence Scheme for Mobile Cooperative Work (CCS-MoCW). This scheme merges features of both stateless and stateful servers. As with stateless approaches, our strategy is based on periodic broadcast of IRs. And as stateful approaches the MUs can request data to the server at any instant without waiting the new IRs. Other stateful feature used is related to the knowledge that the server has about MUs. In the proposed environment, this knowledge is limited because the server does not have complete information about the MUs. However, the server has information about the MUs connection and their activities. The majority of the current strategies for cache coher-
241
the MU disconnection number (d). If d is smaller than P or d is bigger than P and the MU lock is not held by another MU (the lock continues in a vulnerable state), it means that the MU became disconnected but it is still holding the lock. Then, the data can be committed. Otherwise, if the MU lock is held by other MU, the server informs that this id information cannot be updated. If the difference between the MU timestamp and server timestamp is bigger than w, the entire MU cache is dropped. This is because the MU has been disconnected for a long time, and thus there may be some updates that have neither been broadcasted nor stored in h. Then, the server synchronizes the new data with MU.
4
Consistency. Arnald chooses to edit the item Introduction. In this case, the lock status field (in parentheses) is set to the user name Arnald in order to inform other users that the Introduction item is being edited, as shown in Figure 1(b). While Arnald is editing this item (as shown in Figure 1(c)), other users cannot lock Introduction. The lock is only released when Arnald requests to cancel or to commit the operation. If Beatriz tries to lock Introduction while Arnald is editing it, she does not obtain the lock as it is shown in Figure 1(d). In the application if one user tries to lock an item that is being modified by another user, a warning message will be presented.
Usage Scenario
Our development and testing environment consists of two mobile devices (based on Palm Os and with WI-FI interface), a stationary workstation (Linux Ubuntu 6.10) and a wireless LAN infrastructure (IEEE 802.11). The communication between MUs and server is made with TCP/IP sockets. The invalidation reports are broadcasted every 60 seconds (bI), and the update broadcast window is 600 seconds (w). The maximum disconnection period (P) considered is three broadcast IR intervals. The MU client application was developed using Java Micro Edition and the server application uses Java Standard Edition. Derby [1] is the database system component considered for our experiments. A prototype application was developed in order to demonstrate that CCS-MoCW provides the correct behavior for the application. The goal of the collaborative application users is to produce a unique shared document. The document is divided into items where these items can be edited by users. In order to edit, they have to obtain the lock. For entering in a cooperative group, the users have to enter their login and password as presented in Figure 1(a). The server searches for the items related to the text being edited in the cooperative group and the results are returned to MU, which stores this data in cache and presents the results locally. The application lets the user edit, insert and delete items. Figure 1(b) shows the list of all data items that the user can initially work. Each item contains title, content and a field to inform the lock status. The intended use of the lock status is to inform whether the item is being edited by another user. An item can be edited or deleted by selecting it and choosing EDIT or DEL option in the menu. When one of the options is chosen, the server receives a lock message for the id associated to the selected item and verifies the lock status for this id. In order to insert a new item, the user can select an existent item and choose INS option in the menu. Then the new item will be positioned after the item selected. In our sample application, two users are editing a text: Arnald and Beatriz. The text represents an article divided in two sections: Introduction and Data
Beatriz decided to insert a new item. This item is entitled Challenges. She adds the content “In this work we show a list of general challenges for a developer of mobile CSCW” and commits the operation as illustrated in Figure 2(a). Arnald finishes the changes in Introduction after adding the text “the integration of mobile devices in collaborative applications” and commits the operation too. Then he decides to delete the item Data Consistency as presented in Figure 2(b). In the next broadcasts of IR, the server sends information about the items that were updated. A warning message will be presented to users informing that an IR message was received as shown in Figure 2(c). Then the Arnald and Beatriz’s caches are updated. Now, Beatriz’s cache contains the data that was modified by Arnald, and Arnald’s cache contains the new data inserted by Beatriz as shown in Figure 2(d). Now Beatriz obtained the right to edit the item Introduction as presented in Figure 3(a). While she is editing the item, somehow she becomes disconnected. She is still disconnected when Arnald inserts a new item entitled Conclusion (see Figure 3(b)). When she reconnects to wireless cell, she tries to commit her changes. The server receives the request for commit and verifies the Beatriz’s timestamp. In this case, as her timestamp is smaller than the server timestamp, it checks the MU disconnection number (d). If d is bigger than the maximum disconnection period (P) and the MU lock is held by another MU or if the difference between the Beatriz’s timestamp and server timestamp is big-
242
riod 120 operations (including edits, deletes and insertions) were executed on average. The response time for an operation made by an MU is 3 seconds on average. Considering a mobile cooperative environment, this response time is considered acceptable.
5
Conclusions and Future Work
In this paper we propose a scheme for cache coherence strategy for mobile cooperative systems and we implemented the scheme in an application. The implemented strategy ensures the cache coherence using both stateless and stateful approaches and it supports blocking protocol. This paper shows the feasibility of the strategy and addresses a significant technical problem in cooperative systems; however the study is not complete yet. Work currently in progress addresses the improvement of awareness information including modification histories of objects, context information and information about running sessions. Although our testing environment primarily is based on wireless LAN, we aim to be independent as possible from the network. We intend to adapt our environment to run on other wireless networks such as Infrared, Bluetooth and/or GPRS. Some problems are still open and have to be addressed in the future. We aim to analyze the efficiency of our strategy in terms of energy consumption, cache invalidation, disconnection time, and cooperation effectiveness.
ger than w she cannot commit her changes as shown in Figure 3(c). Otherwise, if d is smaller than P or d is bigger than P and the MU lock continues in a vulnerable state, it means that the MU became disconnected but it is still holding the lock. Then, the data item can be committed. Figure 3(d) presents the data item after the commit. In any of the above cases, in the end of cooperation the MU data is synchronized with the server data and the final text is coherent.
References Introduction [1] Apache db project. http://db.apache.org/derby/. [2] D. Barbara and T. Imieliski. Sleepers and workaholics: caching strategies in mobile environments. In SIGMOD ’94: Proceedings of the 1994 ACM SIGMOD international conference on Management of data, pages 1–12, New York, NY, USA, 1994. ACM Press. [3] K. Cheverst, G. Blair, N. Davies, and A. Friday. Supporting collaboration in mobile-aware groupware. Personal Technologies, 3(1):33–42, 1999. [4] A. Madhukar and R. Alhajj. An adaptive energy efficient cache invalidation scheme for mobile databases. pages 1122– 1126, 2006. [5] M.-C. Papadopoulos. Improving awareness in mobile cscw. IEEE Transactions on Mobile Computing, 5(10):1331–1346, 2006. Member-Constantinos Papadopoulos. [6] D. Pinelle and C. Gutwin. A groupware design framework for loosely-coupled workgroups. In Proceedings of the European Conference on Computer-Supported Cooperative Work, 2005. [7] Z. Wang, S. K. Das, H. Che, and M. Kumar. A scalable asynchronous cache consistency scheme (saccs) for mobile environments. In IEEE transactions on parallel and distributed systems. IEEE Computer Society, 2004.
In our strategy we assume that the cooperative group database is only updated by the server. When the user wants to modify his/her data (selecting commit option), he/she sends a request modification message to the server. The modification is confirmed only when the server updates the database. Our preliminary evaluation shows that CCSMoCW offers an acceptable performance in terms of energy consumption and response time in the proposed wireless environment. We adopt as response time the interval between the user request and screen update in the MU. Our study involves two PalmOne LifeDrive equipped with 4GB hard drive, 64MB program memory, Intel 416MHz XScale processor and 1600 mAH battery. We examined the interaction between two users who are producing a unique document in a cooperative way. We always start the experiment with the battery of the device fully loaded. We found that the total Palms’ battery was consumed after 198 minutes. In this pe-
243
Supporting Cache Coherence in Mobile Cooperative Systems Carla Diacui Medeiros Berkenbrock, Celso Massaki Hirata Instituto Tecnol´ogico de Aeron´autica - ITA Department of Computer Science S.J.Campos, SP, Brazil {diacui, hirata}@ita.br
Abstract
bile computing is energy consumption. Mobile users are frequently disconnected from the network or kept in weak connection status to save energy. In addition, the bandwidth of the wireless channel is also limited. Copies of data can be kept in mobile devices to reduce data retrievals from the server. Then, caching data reduces the uplink and downlink bandwidth consumption as well as the average latency in data access. It is also important to consider that wireless communication is one of the major sources of energy consumption that reduces battery life of mobile devices. An important concept in the CSCW area is awareness. Awareness is a feeling of illusion through which participants in a cooperative system can sense the presence of others and their movements by sharing a workspace. Maintaining awareness of the users working context is crucial to successful cooperation. However, considering that mobile users work under resource constraints the information delivered to a mobile device should be restricted to the one that is relevant for the users work. In this paper, we propose a cache coherence scheme for mobile cooperative work. This scheme is based on periodic broadcast of invalidation reports and provides some aspects of awareness information. In addition, we developed a prototype application in order to demonstrate the feasibility of proposed scheme. Our study distinguishes from others in three ways: First, our scheme avoids invalidation cached data by the use of vulnerable locks. Second, the scheme focuses on providing cooperation using the scheme to present awareness information. Third, different from other studies that are only based on simulation models, we demonstrate that our scheme is feasible under a real environment.
Efficient cache coherence strategies are critical to maintain data consistency and provide a reasonable performance of wireless applications with mobile devices. However, the majority of the current strategies for cache coherence in mobile environments have not been designed to be used in cooperative applications. In this paper we propose and describe an implementation of a cache coherence scheme for mobile cooperative work. The scheme is based on periodic broadcast of invalidation reports and provides some aspects of awareness information. The implementation is made through the development of a prototype cooperative application.
1. Introduction Computer-Supported Cooperative Work (CSCW) is a research area that provides both an understanding of how people work together and how systems can be successfully designed to accommodate these work practices. The advance of mobile computing and the new ways of connectivity allow the integration of mobile devices in cooperative applications. Maintaining data consistency is a challenge in building mobile systems because mobile users usually communicate using loose coupled systems and their devices are often disconnected, thus they neither can access the server nor are accessible by other devices all the time. Therefore mobile applications have to allow for such disconnections. Caching data is an interesting strategy to improve the interactive response time, reduce latency, save bandwidth, maintain data consistency, and improve performance in wireless environments. However, considering that mobile units (MUs) can suffer from disconnections and changes of one piece of information on simultaneous form, the usage of mechanism to provide coherence is required. The mechanism must assure that the data caching in MUs are coherent with the stored data in the server. Other key issue for mo-
978-0-7695-3192-2/08 $25.00 © 2008 IEEE DOI 10.1109/NCA.2008.11
2
Related Work
Barbara and Imieliski [2] propose three new cache invalidation strategies that use invalidation reports and a stateless server: Broadcasting Timestamp (TS), Amnesic Terminals (AT), and Signatures (SIG). Wang et al [7] propose a strategy called Scalable Asynchronous Cache Con-
240
sistency Scheme (SACCS), that provides a weak cache consistency, and inherits features of both stateless and stateful approaches. Madhukar and Alhajj [4] present a cache coherence scheme for the wireless mobile environment called Adaptive Energy Efficient Cache Invalidation Scheme (AEECIS), which uses a stateful server and it is adaptive because it changes the data dissemination strategy based on the current conditions. Other work investigates the awareness in mobile environments. Cheverst et al [3] examine the need for a new type of awareness that provides group members with relevant information concerning the effect that the constraints imposed by mobile environment might have on the group’s collaboration. Pinelle and Gutwin [6] discuss the preference that users have for low-cost collaboration such as lowlevel awareness information and asynchronous communication. Papadopoulos [5] investigates opportunities for improving awareness in mobile environments with a view to enable collaboration under power constraints and transitory network disconnections. To the best of our knowledge, we have not found any other work on cache coherence in mobile cooperative applications using blocking protocol and presenting aspects of awareness information. As mentioned, the previous work related to cache coherence has investigated the mobile constraints without considering the requirements of cooperative systems. Therefore strategies for cache coherence in mobile environments which consider energy saving, communication delay, disconnection, for cooperative applications are required. In addition, current cache coherency schemes have not been designed to provide awareness information. We believe that the use of cache coherence mechanisms can facilitate the maintenance of some awareness aspects. For example, the messages exchanged between a mobile user and the server to keep cache coherence can also be used to supply information about both user’s context and activities.
3
ence allow executing operations in a nonblocking manner [2, 4, 7]. Nonblocking protocols are lighter and generally provide better performance for applications where clients are independent from each other. On the other hand, the blocking protocol maintains consistency by preventing actions from users who are not holding the lock. Only operations from the current lock holder are allowed to make state changes to the shared data. As mentioned, in general, nonblocking protocols can achieve better response time than blocking protocols. However, in case of inconsistencies, nonblocking protocols should be able to restore states. The effects of the undo operations in the restoration affect both the system performance and the awareness. Additionally, in order to perform undo operations in mobile cooperative environments consistently, it is required to take into account the frequent MUs disconnections. CCS-MoCW uses blocking protocol to allow that operations be realized so that their effect on shared data can be serially equivalent. Additionally, we use timeouts to detect disconnections and avoid that a disconnected MU holding a lock can lead to deadlock. The server broadcasts an IR every bI seconds. When the MU receives an IR, it returns an “ack” message to server. The server receives the “ack” messages, then it reports which MUs are disconnected. If the MU remains disconnected for longer than a maximum disconnection period (P) its lock becomes vulnerable. If any other MU wants to access a vulnerable lock, the server releases the vulnerable lock and the lock is granted to the other MU. When an MU enters in the cooperative group, it receives a timestamp from server. The timestamp is used to monitor the MUs’ cache and to verify if the version of its cache is coherent with the data in the server. The MU timestamp is always assigned by the server. So we do not have the problem of generating different timestamps. Thereafter, the MU can request access to an object for updating. To each record in the cooperative group it is assigned a unique record identifier (id). When the server receives a lock message for an id, it verifies if no other MU is holding a lock for this id or if there is a vulnerable lock for this id. In both cases, the lock is granted and the server verifies if the requested data item was changed after the last sent message of IR information. In case of change, the server sends the last version data to MU. So there is no way the MU can overwrite and invalidate information already committed. The commit message is used to insert, delete or modify data. Before modifying or deleting an item, it is necessary to hold the lock for the correspondent id. When the server receives a commit message for an id, it compares the MU timestamp with the server timestamp. If the MU timestamp is equal to the server timestamp, it means that the MU data is coherent with the server’s data. Then, the server stores the updates in the history of updates (h) and releases the lock. If the MU timestamp is smaller than the server timestamp, it checks
Cache Coherence Scheme for Mobile Cooperative Work
In this section, we propose a Cache Coherence Scheme for Mobile Cooperative Work (CCS-MoCW). This scheme merges features of both stateless and stateful servers. As with stateless approaches, our strategy is based on periodic broadcast of IRs. And as stateful approaches the MUs can request data to the server at any instant without waiting the new IRs. Other stateful feature used is related to the knowledge that the server has about MUs. In the proposed environment, this knowledge is limited because the server does not have complete information about the MUs. However, the server has information about the MUs connection and their activities. The majority of the current strategies for cache coher-
241
the MU disconnection number (d). If d is smaller than P or d is bigger than P and the MU lock is not held by another MU (the lock continues in a vulnerable state), it means that the MU became disconnected but it is still holding the lock. Then, the data can be committed. Otherwise, if the MU lock is held by other MU, the server informs that this id information cannot be updated. If the difference between the MU timestamp and server timestamp is bigger than w, the entire MU cache is dropped. This is because the MU has been disconnected for a long time, and thus there may be some updates that have neither been broadcasted nor stored in h. Then, the server synchronizes the new data with MU.
4
Consistency. Arnald chooses to edit the item Introduction. In this case, the lock status field (in parentheses) is set to the user name Arnald in order to inform other users that the Introduction item is being edited, as shown in Figure 1(b). While Arnald is editing this item (as shown in Figure 1(c)), other users cannot lock Introduction. The lock is only released when Arnald requests to cancel or to commit the operation. If Beatriz tries to lock Introduction while Arnald is editing it, she does not obtain the lock as it is shown in Figure 1(d). In the application if one user tries to lock an item that is being modified by another user, a warning message will be presented.
Usage Scenario
Our development and testing environment consists of two mobile devices (based on Palm Os and with WI-FI interface), a stationary workstation (Linux Ubuntu 6.10) and a wireless LAN infrastructure (IEEE 802.11). The communication between MUs and server is made with TCP/IP sockets. The invalidation reports are broadcasted every 60 seconds (bI), and the update broadcast window is 600 seconds (w). The maximum disconnection period (P) considered is three broadcast IR intervals. The MU client application was developed using Java Micro Edition and the server application uses Java Standard Edition. Derby [1] is the database system component considered for our experiments. A prototype application was developed in order to demonstrate that CCS-MoCW provides the correct behavior for the application. The goal of the collaborative application users is to produce a unique shared document. The document is divided into items where these items can be edited by users. In order to edit, they have to obtain the lock. For entering in a cooperative group, the users have to enter their login and password as presented in Figure 1(a). The server searches for the items related to the text being edited in the cooperative group and the results are returned to MU, which stores this data in cache and presents the results locally. The application lets the user edit, insert and delete items. Figure 1(b) shows the list of all data items that the user can initially work. Each item contains title, content and a field to inform the lock status. The intended use of the lock status is to inform whether the item is being edited by another user. An item can be edited or deleted by selecting it and choosing EDIT or DEL option in the menu. When one of the options is chosen, the server receives a lock message for the id associated to the selected item and verifies the lock status for this id. In order to insert a new item, the user can select an existent item and choose INS option in the menu. Then the new item will be positioned after the item selected. In our sample application, two users are editing a text: Arnald and Beatriz. The text represents an article divided in two sections: Introduction and Data
Beatriz decided to insert a new item. This item is entitled Challenges. She adds the content “In this work we show a list of general challenges for a developer of mobile CSCW” and commits the operation as illustrated in Figure 2(a). Arnald finishes the changes in Introduction after adding the text “the integration of mobile devices in collaborative applications” and commits the operation too. Then he decides to delete the item Data Consistency as presented in Figure 2(b). In the next broadcasts of IR, the server sends information about the items that were updated. A warning message will be presented to users informing that an IR message was received as shown in Figure 2(c). Then the Arnald and Beatriz’s caches are updated. Now, Beatriz’s cache contains the data that was modified by Arnald, and Arnald’s cache contains the new data inserted by Beatriz as shown in Figure 2(d). Now Beatriz obtained the right to edit the item Introduction as presented in Figure 3(a). While she is editing the item, somehow she becomes disconnected. She is still disconnected when Arnald inserts a new item entitled Conclusion (see Figure 3(b)). When she reconnects to wireless cell, she tries to commit her changes. The server receives the request for commit and verifies the Beatriz’s timestamp. In this case, as her timestamp is smaller than the server timestamp, it checks the MU disconnection number (d). If d is bigger than the maximum disconnection period (P) and the MU lock is held by another MU or if the difference between the Beatriz’s timestamp and server timestamp is big-
242
riod 120 operations (including edits, deletes and insertions) were executed on average. The response time for an operation made by an MU is 3 seconds on average. Considering a mobile cooperative environment, this response time is considered acceptable.
5
Conclusions and Future Work
In this paper we propose a scheme for cache coherence strategy for mobile cooperative systems and we implemented the scheme in an application. The implemented strategy ensures the cache coherence using both stateless and stateful approaches and it supports blocking protocol. This paper shows the feasibility of the strategy and addresses a significant technical problem in cooperative systems; however the study is not complete yet. Work currently in progress addresses the improvement of awareness information including modification histories of objects, context information and information about running sessions. Although our testing environment primarily is based on wireless LAN, we aim to be independent as possible from the network. We intend to adapt our environment to run on other wireless networks such as Infrared, Bluetooth and/or GPRS. Some problems are still open and have to be addressed in the future. We aim to analyze the efficiency of our strategy in terms of energy consumption, cache invalidation, disconnection time, and cooperation effectiveness.
ger than w she cannot commit her changes as shown in Figure 3(c). Otherwise, if d is smaller than P or d is bigger than P and the MU lock continues in a vulnerable state, it means that the MU became disconnected but it is still holding the lock. Then, the data item can be committed. Figure 3(d) presents the data item after the commit. In any of the above cases, in the end of cooperation the MU data is synchronized with the server data and the final text is coherent.
References Introduction [1] Apache db project. http://db.apache.org/derby/. [2] D. Barbara and T. Imieliski. Sleepers and workaholics: caching strategies in mobile environments. In SIGMOD ’94: Proceedings of the 1994 ACM SIGMOD international conference on Management of data, pages 1–12, New York, NY, USA, 1994. ACM Press. [3] K. Cheverst, G. Blair, N. Davies, and A. Friday. Supporting collaboration in mobile-aware groupware. Personal Technologies, 3(1):33–42, 1999. [4] A. Madhukar and R. Alhajj. An adaptive energy efficient cache invalidation scheme for mobile databases. pages 1122– 1126, 2006. [5] M.-C. Papadopoulos. Improving awareness in mobile cscw. IEEE Transactions on Mobile Computing, 5(10):1331–1346, 2006. Member-Constantinos Papadopoulos. [6] D. Pinelle and C. Gutwin. A groupware design framework for loosely-coupled workgroups. In Proceedings of the European Conference on Computer-Supported Cooperative Work, 2005. [7] Z. Wang, S. K. Das, H. Che, and M. Kumar. A scalable asynchronous cache consistency scheme (saccs) for mobile environments. In IEEE transactions on parallel and distributed systems. IEEE Computer Society, 2004.
In our strategy we assume that the cooperative group database is only updated by the server. When the user wants to modify his/her data (selecting commit option), he/she sends a request modification message to the server. The modification is confirmed only when the server updates the database. Our preliminary evaluation shows that CCSMoCW offers an acceptable performance in terms of energy consumption and response time in the proposed wireless environment. We adopt as response time the interval between the user request and screen update in the MU. Our study involves two PalmOne LifeDrive equipped with 4GB hard drive, 64MB program memory, Intel 416MHz XScale processor and 1600 mAH battery. We examined the interaction between two users who are producing a unique document in a cooperative way. We always start the experiment with the battery of the device fully loaded. We found that the total Palms’ battery was consumed after 198 minutes. In this pe-
243
