We introduce different mobile network applications and show to which degree the concept of database transactions is required within the applications. We show properties of transaction processing and explain which properties are important for each of the mobile applications. Furthermore, we discuss open questions regarding transaction processing in mobile networks and identify open problems for further research

Chrysanthis, Panos Kypros

Delis, Alex

Gruenwald, Le

Mondal, Anirban

Obermeier, Sebastian

Ouksel, Aris

Samaras, George

Viglas, Stratis

Dagstuhl Research Online Publication Server

06431 – Working Group Summary— Atomicity in Mobile Networks —Dagstuhl SeminarScalable Data Management in Evolving NetworksJoos-Hendrik Bo¨se1, Stefan Bo¨ttcher2, Panos Kypros Chrysanthis3, AlexDelis4, Le Gruenwald5, Anirban Mondal6, Sebastian Obermeier2, Aris Ouksel7,George Samaras8, Stratis D. Viglas91 Freie Universitt Berlin, Germanyboese@mi.fu-berlin.de2 University of Paderborn, Germanystb | so @upb.de3 University of Pittsburgh, USApanos@cs.pitt.edu4 National and Capodistrian University of Athens, Greecead@di.uoa.gr5 US National Science Foundation - Arlington, USAggruenwald@ou.edu6 University of Tokyo, Japananirban@tkl.iis.u-tokyo.ac.jp7 University of Illinois at Chicago, USAaris@uic.edu8 University of Cyprus, Cypruscssamara@cs.ucy.ac.cy9 University of Edinburgh, UKsviglas@inf.ed.ac.ukAbstract. We introduce different mobile network applications and showto which degree the concept of database transactions is required withinthe applications. We show properties of transaction processing and ex-plain which properties are important for each of the mobile applications.Furthermore, we discuss open questions regarding transaction processingin mobile networks and identify open problems for further research.Keywords. Data Management for Evolving Networks, Mobile Transac-tions, Atomicity1 IntroductionMobile devices are becoming more and more popular, and are going to beequipped with a processing capability that exceeds that of a workstation PCof the year 2000. Mobile networks are expected to fulfill the vision that eachDagstuhl Seminar Proceedings 06431Scalable Data Management in Evolving Networkshttp://drops.dagstuhl.de/opus/volltexte/2007/9522 Bo¨se, Bo¨ttcher, Chrysanthis, Delis, Gruenwald, Mondal, Obermeier, Ouksel, Samaras, Viglasand every device is connected to one another, which has an enormous impacton our everyday life. However, the use of mobile devices in business transactionswill be limited as long as there is no adequate support for mobile transactions.In the following, we will point out different applications of mobile transactions(Section 2) and conduct investigations on the need for transaction processingsupport in the explained applications (Section 3). Furthermore, we outline openresearch topics and main challenges in Section 4 and give a short summary andconclusions in Section 5.2 Example Applications for MANETSThere are several basic applications for MANETS, for which we will explainwhether transactions are useful.Rescue applications use mobile networks to communicate with different ma-chines and human beings. A rescue application for firefighters can be usedto develop rescue plans and form virtual teams of different fire brigades.Furthermore, the mobile networks can be used to locate fire trucks and givemoving instructions to them. In such a scenario, there is the need for trans-action support in the sense, that fire trucks and fire fighters are considered asresources that receive instructions. Since resources cannot perform contra-dictory instructions at the same time and most plans require that more thanone unit processes the instructions, properties like atomicity and isolationmust be supported.Mars rovers explore the surface of the Mars by collecting measurements, tak-ing rock samples and comparing them to previously identified materials. Inorder to analyze the surface of the planet, the Mars rovers must furthercombine their locally measured data with data that is already present inthe network. Therefore, the network serves as a large database. While sometypes of Mars rovers move fast, some of them move at a moderate speed.To apply well tried and tested standard distributed database technology insuch a scenario, we need a non-blocking atomic commit protocol that notonly stabilizes the coordination process, but also reduces the blocking of par-ticipating databases, especially if the databases are suspected to frequentlydisconnect from the network, like moving Mars rovers do.Homecare applications assist a nurse having mobile devices like PDAs to getinformation about the patient. Transaction support is required whenever pa-tient data, medicine data, or subscriptions get updates. However, the amountof transactions is usually very low. Therefore, the concurrency control mech-anisms used do not need to be efficient regarding the transaction throughput,but they must be efficient regarding the blocking of data.M-Commerce scenarios like mobile auction applications assist sellers and buy-ers of a flea market in terms of searching and localizing desired items. Fur-thermore, contracts between several buyers can be signed to gain volume06431 – Working Group Summary 3discounts. Transaction support is necessary in order to achieve consistencyfor contracts and buying/selling actions.3 Properties of Transaction Processing in MANETSTransaction processing in MANETs involves new challenges compared to fixedwired networks. We will explain different properties and show whether they areapplicable to the mobile applications introduced in Section 2.Transaction ThroughputAlthough a smaller amount of transactions must be processed in mobile net-works, the throughput varies from application to application. Therefore, theprotocols and concurrency control mechanisms used must take the transac-tion throughput into consideration.Minimized Blocking TimeThe time that the transaction processing nodes must block their resourcesmust be minimized for some applications. The following dependency existsbetween the concurrency situation and the blocking time: The blocking ofresources that are never needed by concurrent transactions has no harmfuleffect. Therefore, if there is no concurrency, the blocking time must not beminimized. [1] proved that there is no non-blocking atomic commit protocolin the sense that the transaction processing nodes must block the data afterthey have sent their commit vote on the transaction.ConcurrencyThe amount of parallelly processed transactions effects the the choice foroptimistic or pessimistic concurrency control mechanisms. Furthermore, theamount of conflicting transactions that must be processed concurrently in-fluences the blocking time.AtomicityWhenever a transaction consists of more than one sub-transaction, atomiccommit protocols can be used to ensure an atomic transaction execution.Table 1 shows the importance of different transaction properties for the ap-plications in our example. As we can see, atomicity is an important propertywhose support is essential for a lot of applications. In the following, we willinvestigate the challenges of guaranteeing atomicity in mobile networks.4 Challenges and Research Topics in the Field ofGuaranteeing AtomicityWe have identified the following challenges and open questions for atomic trans-action processing in mobile networks:Guaranteeing global data integrityOne of the main challenges which motivates the use of atomic commit pro-tocols is to guarantee global integrity constraints. If transactions are not4 Bo¨se, Bo¨ttcher, Chrysanthis, Delis, Gruenwald, Mondal, Obermeier, Ouksel, Samaras, ViglasApplicationTransactionThroughputNeed forReducedBlockingTimeConcurrency AtomicityRescue App. high criticalonly onecommand at atimerequiredMars Rovers medium medium highdepending ondesiredconsistencyHomecare low low low requiredM-Commercedepending onmarketsituationmedium mediumrequired fordistributedtransactionsTable 1. Transaction properties for different applicationsprocessed in an atomic fashion, the result can harm integrity constraints.How can we ensure that defined global integrity constraints hold even if wehave completely independent database systems?Global Commit −→ Individual CommitHow can we break down the global commit decision to a set of individualcommit decisions, in order to decentralize the commit decision making pro-cess?Localize Commit DecisionsHow can participants efficiently localize commit decisions in the network,even if participants fail? To which extend should the commit decision bedisseminated in order to be reliably stored?Disconnections and Network PartitioningIn mobile networks, disconnections may occur at any time and are no failureat all. Furthermore, network partitioning can divide the network into severalpartitions that cannot communicate with each other. How can we design aprotocol that does not suffer from network partitioning as much as currentprotocols do?One Sided DisconnectionsIn comparison to disconnections and network partitioning, in scenarios withone sided disconnections, some participants may only receive messages butare not able to send messages to other participants, e.g. due to a low battery,limited transmitting power, or geographical issues. Can we define a protocolthat takes advantage of the one sided disconnection?06431 – Working Group Summary 5Reduce Risk of Infinite BlockingAlthough the possibility of having an infinite blocking is proven to be un-avoidable [1], we may not only reduce the chance that this infinite blockingoccurs by reducing the time frame in which participants are blocked (cf. e.g.[2]), we may also want to reduce the number of blocked participants usingmultiple coordinators (cf. e.g. [3]). Can we find criteria that allow us to pre-dict whether some participants are more susceptible to infinite blocking thanothers?Sacrifice Consistency for EnergyCan we sacrifice consistency constraints in order to save energy? How can wedetect inconsistent states and how can we repair inconsistent participants?Redo / Retry in Case of FailuresWhen a failure occurs during transaction processing, how can we reuse oldresults to a maximum extent instead of repeating the whole transaction?Can we redo only parts of the transaction without losing serializability?HeuristicsCan we identify situations in which relaxing atomicity or consistency is notharmful? Think, for example, of a rescue operation that has blocked resourcesbut does not reach a commit decision. In such a case, relaxing atomicitywould mean that other transactions can be processed first even if the blockedtransaction cannot be committed anymore. Can we use a heuristic approachto ensure consistency and compensate later on by spawning new transactionsthat restore consistency? Can we, as another possibility, compensate to anequivalent prior state instead of compensating the transaction? To whatextent do we have to allow inconsistency between certain points in time inorder to speed up transaction execution?5 Summary and ConclusionsWe have introduced different application scenarios based on mobile networks,which all have in common that they profit from transaction support. However,as we pointed out, each scenario has individual properties that must be sup-ported. Furthermore, we have shown open research questions and challenges fortransaction processing in mobile networks. In summary, research on transactionexecution in mobile networks is still a challenging and interesting topic.References1. Bernstein, P.A., Hadzilacos, V., Goodman, N.: Concurrency Control and Recoveryin Database Systems. Addison-Wesley (1987)2. Bo¨ttcher, S., Gruenwald, L., Obermeier, S.: Reducing sub-transaction aborts andblocking time within atomic commit protocols. In: BNCOD. (2006) 59–723. Bo¨se, J.H., Bo¨ttcher, S., Gruenwald, L., Obermeier, S., Schweppe, H., Steenweg, T.:An integrated commit protocol for mobile network databases. In: 9th InternationalDatabase Engineering & Application Symposium IDEAS, Montreal, Canada (2005)

06431 Working Group Summary: Atomicity in Mobile Networks

http://drops.dagstuhl.de/opus/volltexte/2007/952/pdf/06431.ObermeierSebastian.Paper.952.pdf

06431 Working Group Summary: Atomicity in Mobile Networks

Abstract

Similar works

Full text

Available Versions

Dagstuhl Research Online Publication Server