6/30/2015 01:07 1 Mobile and Wireless Database Access for Pervasive Computing Panos K. Chrysanthis University of Pittsburgh & Carnegie Mellon University.

6/30/2015 01:07 1 Mobile and Wireless Database Access for Pervasive Computing Panos K. Chrysanthis University of Pittsburgh & Carnegie Mellon University Evaggelia Pitoura University of Ioannina panos@cs.pitt.edupanos@cs.pitt.edu pitoura@cs.uoi.grpitoura@cs.uoi.gr An IEEE ICDE 2000 Tutorial on

6/30/2015 01:07 2 Outline  Motivating Example  Issues: Mobility, Wireless Communication, Portability  Adaptability and Mobile Client-Server Models  Location Management  Broadcast data dissemination  Disconnected database operations  Mobile Access to the Web  Mobility in Workflow Systems  State of Mobile DB Industry and Research Projects  Unsolved Problems

6/30/2015 01:07 3 Party on Friday  Update Smart Phone’s calendar with guests names.  Make a note to order food from Dinner-on- Wheels.  Update shopping list based on the guests drinking preferences.  Don’t forget to swipe that last can of beer’s UPS label.  The shopping list is always up-to-date.

6/30/2015 01:07 4 Party on Friday  AutoPC detects a near Supermarket that advertises sales.  It accesses the shopping list and your calendar on the Smart Phone.  It informs you the soda and beer are on sale, and reminds you. that your next appointment is in 1 hour.  There is enough time based on the latest traffic report.

6/30/2015 01:07 5 Party on Friday  TGIF…  Smart Phone reminds you that you need to order food by noon.  It downloads the Dinner-on-Wheels menu from the Web on your PC with the guests’ preferences marked.  It sends the shopping list to your CO-OP’s PC.  Everything will be delivered by the time you get home in the evening.

6/30/2015 01:07 6 Mobile Applications  Expected to create an entire new class of Applications  new massive markets in conjunction with the Web  Mobile Information Appliances - combining personal computing and consumer electronics  Applications:  Vertical: vehicle dispatching, tracking, point of sale  Horizontal: mail enabled applications, filtered information provision, collaborative computing…

6/30/2015 01:07 7 Mobile and Wireless Computing  Goal: Access Information Anywhere, Anytime, and in Any Way.  Aliases: Mobile, Nomadic, Wireless, Pervasive, Invisible, Ubiquitous Computing.  Distinction: Fixed wired network: Traditional distributed computing. Fixed wireless network: Wireless computing. Wireless network: Mobile Computing.  Key Issues: Wireless communication, Mobility, Portability.

6/30/2015 01:07 8 Wireless Communication  Cellular - GSM (Europe+), TDMA & CDMA (US) –FM: 1.2-9.6 Kbps; Digital: 9.6-14.4 Kbps (ISDN-like services)  Public Packet Radio - Proprietary –19.2 Kbps (raw), 9.6 Kbps (effective)  Private and Share Mobile Radio  Wireless LAN - wireless LAN bridge (IEEE 802.11) –Radio or Infrared frequencies: 1.2 Kbps-15 Mbps  Paging Networks – typically one-way communication –low receiving power consumption  Satellites – wide-area coverage (GEOS, MEOS, LEOS) –LEOS: 2.4 Kbps (uplink), 4.8Kbps (downlink)

6/30/2015 01:07 9 Mobile Network Architecture

6/30/2015 01:07 10 Future Wireless Communication Source: Rysavy Research, 1999 TechnologyServiceData CapabilityExpected Deployment GSM High-speed circuit-switched28.8 to 56 Kbps service likelyLimited 1999 and 2000 General Packet Radio ServiceIP and X.25 over KbpsRollout of service 2001 Enhanced Data Rates for GSM Evolution IP to 384 Kbps. Roaming with IS-136 networks Rollout of service 2002 Wideband CDMASimilar to EDGE but adds 2Mbps indoor capability Initial in 2002 or 2003 IS-136 TDMA EDGEIP to 384 Kbps. Roaming with GSM networks Initial in 2002 or 2003 WCDMA or WidebandSimilar to EDGE but adds 2Mbps indoor capability No stated deployment plans CDMA IS-95BIP communications: 64 KbpsJapanese markets in 2000 CDMA2000-1XRTTIP communications: 144 KbpsTrial in 2001, rollout 2002 CDMA2000 - 3XRTTIP: 384 Kbps(out), 2 Mbps(in)Initial in 2002 or 2003

6/30/2015 01:07 11 Wireless characteristics  Variant Connectivity  Low bandwidth and reliability  Frequent disconnections predictable or sudden  Asymmetric Communication  Broadcast medium  Monetarily expensive  Charges per connection or per message/packet  Connectivity is weak, intermittent and expensive

6/30/2015 01:07 12 Portable Information Devices  PDAs, Personal Communicators  Light, small and durable to be easily carried around  dumb terminals [InfoPad, ParcTab projects], palmtops, wristwatch PC/Phone, walkstations  will run on AA+ /Ni-Cd/Li-Ion batteries  may be diskless  I/O devices: Mouse is out, Pen is in  wireless connection to information networks  either infrared or cellular phone  specialized HW (for compression/encryption)

6/30/2015 01:07 13 Portability Characteristics  Battery power restrictions  transmit/receive, disk spinning, display, CPUs, memory consume power  Battery lifetime will see very small increase  need energy efficient hardware (CPUs, memory) and system software  planned disconnections - doze mode  Power consumption vs. resource utilization

6/30/2015 01:07 14 Portability Characteristics  Resource constraints  Mobile computers are resource poor  Reduce program size – interpret script languages (Mobile Java?)  Computation and communication load cannot be distributed equally  Small screen sizes  Asymmetry between static and mobile computers

6/30/2015 01:07 15 Mobility Characteristics  Location changes location management - cost to locate is added to communication  Heterogeneity in services  bandwidth restrictions and variability  Dynamic replication of data data and services follow users  Querying data - location-based responses  Security and authentication  System configuration is no longer static

6/30/2015 01:07 16 What Needs to be Reexamined?  Operating systems  File systems  Data-based systems  Communication architecture and protocols  Hardware and architecture  Real-Time, multimedia, QoS  Security  Application requirements and design  PDA design: Interfaces, Languages

6/30/2015 01:07 17 Query/Transaction Processing  Concern moves from CPU time and network delays to battery power and communication costs (including tariffs)  Updates may take the form of long-running transactions  nodes may continue in disconnected mode  need new transaction models [Chrysanthis 93, Satya 94]  Move data vs. move query/transaction  Context (location) based query responses  Consistency, autonomy, recovery  Approximate answers  Stable storage for logs, data -- stabilize at servers?  Providing uniform access in a heterogeneous environment  Design of human-computer interfaces (pen-based computing)  Updated system info: Location information, user profiles

6/30/2015 01:07 18 Recurrent Themes  Handling disconnections (planned failures?)  caching strategies  managing inconsistencies  Delayed write-back and prefetch: use network idle times  increases memory requirements  Buffering/batching: allows bulk transfers  Partitioning and replication  triggered by relocation  Compression: increase effective BW  increases battery power requirements  Receiving needs less power than sending

6/30/2015 01:07 19 Issues in Information Provision  tariff  scalability: massive # users accessing read-only data  security (of data and user profiles/location)  impersonation, theft, trust  consuming resources in a foreign environment  damage to fixed hosts?  approximate answers  consistency, autonomy, recovery  PDAs are unreliable  prioritization of actions upon reconnection  providing uniform access in a heterogeneous environment  design of human-computer interfaces (pen-based computing)

6/30/2015 01:07 21 Mobility in Db Applications Need to adapt to constantly changing environment: network connectivity available resources and services By varying and (re)negotiating: the partition of duties between the mobile and static elements the quality of data available at the mobile host Example: Fidelity (degree to which a copy of data matches the reference copy at the server)

6/30/2015 01:07 22 Laissez-FaireApplication Transparent Application-Aware (+) existing applications continue to work unchanged (-) too general, cannot take advantage application semantics (-) may not be attainable (e.g., during a long disconnection) (-) applications must be re-written which may be very complicated (-) no focal point of control to resolve potentially incompatible application demands or to enforce limits on resource usage Adaptability Where should support for mobility and adaptability be placed?

6/30/2015 01:07 23 Adaptive Applications  Need:  Measurement of QoS and communication with application –A mechanism to monitor the level and quality of information and inform applications about changes.  Programmer Interface for Application-Aware Adaptation –Applications must be agile: able to reveive events in an asynchronous manner and react appropriately  A central point for managing resources and authorizing any application-initiated request.

6/30/2015 01:07 24 Application Awareness  Need for. A mechanism to monitor the level and quality of information and inform applications about changes. Applications must be agile: able to reveive events in an asynchronous manner and react appropriately (triggers) A central point for managing resources and authorizing any application-initiated request.

6/30/2015 01:07 25 Client Server Agent Fixed Network Wireless Link C-SA-C: Server-side Agent  C-SA-C : The Client/Server-side Agent/Server Model  Splits the interaction between the mobile client and server: client-agent and agent-server different protocols for each part of the interaction each part may be executed independently of the other

6/30/2015 01:07 26 Responsibilities of the Agent  Messaging and queying  Manipulate data prior to their transmission to the client:  perform data specific compression  batch together requests  change the transmission order

6/30/2015 01:07 27 Role of the Agent  Surrogate or proxy of the client  Any communication to/from the client goes through the agent  Offload functionality from the client to the agent  Application (service) specific  provides a mobile-aware layer to specifc services or applications (e.g., web-browsing or database access)  handles all requests from mobile clients  Filters  provide agents that operate on protocols  E.g., an MPEG-agent or a TCP-agent

6/30/2015 01:07 28 C-CA-S: Client-side Agent  C-SA-S : The Client/Client-side Agent/Server Model  caching  background prefetching and hoarding  various communication optimizations Mobile Host Client Server Agent Fixed Network Wireless Link

6/30/2015 01:07 29 Mobile Host ClientServerAgent Fixed Network Wireless Link Agent C-I-S: Client & Server Agents  C-I-S : Client/Intercept/Server Model  Caching, prefetching etc  various communication optimizations at both ends –E.g., asynchronous queued RPC  relocate computation between the agents  Client interoperability

6/30/2015 01:07 30 Mobile Agents  Mobile agents are migrating processes associated with an itinerary  dynamic code and state deployment  Implement the agents of the previous architectures as mobile agents, E.g.,  server-side agents can relocate during handoff  client-side agent dynamically move on and off the client –Relocatable dynamic objects (RDO) [Rover]  Implement the communication using mobile agents:  clients submit/receive mobile agents to/from the server  E.g., Compacts [Pro-Motion]

6/30/2015 01:07 31 A Taxonomy

6/30/2015 01:07 33 Locating Moving Objects  Example of moving objects  mobile devices (cars, cellular phones, palmtops, etc)  mobile users (locate users independently of the device they are currently using)  mobile software (e.g., mobile agents)  How to find their location - Two extremes  Search everywhere  Store their current location everywhere  Searching vs. Informing

6/30/2015 01:07 34 Locating Moving Objects  What (granularity), where (availability) and when (currency) to store Availability nowhere at all sites At selective sites (e.g., at frequent callers) Currency Never update Always update (at each movement) Granularity Exact location the whole network some partition

6/30/2015 01:07 35 Architectures of Location DBs  Two-tier Schemes (similar to cellular phones)  Home Location Register (HLR): store the location of each moving object at a pre-specified location for the object  Visitor Location Register (VLR): also store the location of each moving object mo at a register at the current region  Hierarchical Schemes  Maintain multiple registries

6/30/2015 01:07 36 Two-tier Location DBs  Search  Check the VLR at your current location  If object not in, contact the object’s HLR  Update  Update the old and new VLR  Update the HLR

6/30/2015 01:07 37 Hierarchical Location DBs Maintain a hierarchy of location registers (databases) A location database at a higher level contains location information for all objects below it

6/30/2015 01:07 38 Hierarchical Location DBs Call caller

6/30/2015 01:07 39 Hierarchical Location DBs Move old location new location

6/30/2015 01:07 40 Hierarchical vs. Two-tier (+) No pre-assigned HLR (+) Support Locality (-) Increased number of operations (database operations and communication messages) (-) Increased load and storage requirements at the higher-levels

6/30/2015 01:07 41 Locating Moving Objects Partitions P1 P2 P3 P4P5 User x

6/30/2015 01:07 42 Locating Moving Objects  Caching  cache the callee’s location at the caller (large Call to Mobility Ratio)  Replication  replicate the location of a moving object at its frequent callers (large CMR)  Forwarding Pointers  do not update the VLR and the HLR, leave a forwarding pointer from the old to the new VLR (small CMR)  When and how forwarding pointers are purged?  Concurrency, coherency and recovery/checkpointing of location DBs

6/30/2015 01:07 43 Querying Moving Objects Besides locating moving objects, answer more advanced queries, e.g., find the nearest service send a message to all mobile objects in a specific geographical reafion Location queries: spatial, temporal or continuous Issues: representation, evaluation and imprecision Most current research assumes a centralized location database

6/30/2015 01:07 44 Querying Moving Objects How to model the location of moving objects? Dynamic attribute (its value change with time without an explicit update) [e.g., in MOST] For example, dynamic attribute A with three sub-attributes: A.value, A.updatetime and A.function (function of a single variable t that has value 0 at time t=0) The value of A at A.updatetime is A.value at time A.updatetime + t0 is A.value + A.function(t0)

6/30/2015 01:07 45 Querying Moving Objects How to represent and index moving objects?  Spatial indexes do not work well with dynamically changing values  Value-time representation An object is mapped to a trajectory [Kollios 99]

6/30/2015 01:07 47 Information Dissemination Goal : Maximize query capacity of servers, minimize energy per query at the client. Focus: Read-only transactions (queries). –Clients send update data to server –Server resolves update conflicts, commits updates 1. Pull: PDAs demand, servers respond.  backchannel (uplink) is used to request data and provide feedback.  poor match for asymmetric communication.

6/30/2015 01:07 48 Information Dissemination… 2. Push: Network servers broadcast data, PDA's listen.  PDA energy saved by needing receive mode only.  scales to any number of clients.  data are selected based on profiles and registration in each cell. Server Clients A B C D G F E.

6/30/2015 01:07 49 Information Dissemination… Server Clients A B C D G F E. 14.4 Kbps 3. Combinations Push and Pull (Sharing the channel).  Selective Broadcast: Servers broadcast "hot" information only.  "publication group" and "on-demand" group.  On-demand Broadcast: Servers choose the next item based on requests.  FCFS or page with maximum # of pending requests.

6/30/2015 01:07 50 Broadcast Data Dissemination  business data, e.g., Vitria, Tibco  election coverage data  stock related data  traffic information  sportscasts, e.g., Praja  Datatacycle [Herman]  Broadcast disks Data Server

6/30/2015 01:07 51 Organization of Broadcast data  Flat : broadcast the union of the requested data cyclic.  Skewed (Random):  broadcast different items with different frequencies.  goal is that the inter-arrival time between two instances of the same item matches the clients' needs. A B C A A B C

6/30/2015 01:07 52 Broadcast Disks  Multi-Disks Organization [Acharya et. al, SIGMOD95]  The frequency of broadcasting each item depends on its access probability.  Data broadcast with the same frequency are viewed as belonging to the same disk.  Multiple disks of different sizes and speeds are superimposed on the broadcast medium.  No variant in the inter-arrival time of each item. BC A Disk1 Disk2 A B A C

6/30/2015 01:07 53 Selective Tuning  Basic broadcast access is sequential  Want to minimize client's access time and tuning time.  active mode power is 250mW, in doze mode 50μW  What about using database access methods?  Hashing: broadcast hashing parameters h(K)  Indexing: index needs to be broadcast too  "self-addressable cache on the air" (+) "listening/tuning time" decreases (-) "access time" increases

6/30/2015 01:07 54 Access Protocols  Two important factors affect access time: 1.Size of the broadcast 2.Directory miss factor - you tune in before your data but after your directory to the data! Trade-Off:  Size means  Miss factor Trade-Off:  Size means  Miss factor

6/30/2015 01:07 55 Indexing  (1,M) Indexing :  We broadcast the index M times during one version of the data.  All buckets have the offset to the beginning of the next index segment. o Distributed Indexing  Cuts down on the replication of index material  Divides the index into: –replicated top L levels, non-replicated bottom 4- L levels o Flexible Indexing  Broadcast divided into p data segments with sorted data.  A binary control index is used to determine the data segment  A local index to locate the specific item within the segment

6/30/2015 01:07 56 Caching in Broadcasting  Data are cache to improve access time  Lessen the dependency on the server's choice of broadcast priority  Traditionally, clients cache their "hottest" data to improve hit ratio  Cache data based on PIX: Probability of access (P)/Broadcast frequency (X).  Cost-based data replacement is not practical:  requires perfect knowledge of access probabilities  comparison of PIX values with all resident pages  Alternative: LIX, LRU with broadcast frequency  pages are placed on lists based on their frequency (X)  lists are ordered based on L, the running avg. of interaccess times  page with lowest LIX = L/X is replaced

6/30/2015 01:07 57 Prefetching in Broadcasting  Client prefetch page in anticipation of future accesses  No additional load to the server and network  Prefetching instead of waiting for page miss can reduce the cost of a miss  PT prefetching heuristic [Archarya et al. 96] - pt: Access Probability (P) * period (T) before page appears next - A broadcast page b replaces the cached page c with lowest pt value  Team tag - Teletext approach [Ammar 87]  Each page is associated with a set of pages most likely to be requested next  When p is requested, D (D:cache size) associated pages are prefetched  Prefetching stops when client submit a new request

6/30/2015 01:07 58 Cache Invalidation Techniques  When?  Synchronous: send invalidation reports periodically  Asynchronous: send invalidation information for an item as soon as its value changes; E.g., Bit Sequences [Jing 95]  To whom?  Stateful server: to affected clients  Stateless server: broadcast to everyone  What?  invalidation: only which items were updated  propagation: the values of updated items are sent  aggregated information/ materialized views

6/30/2015 01:07 59 Synchronous Invalidation  Stateless servers are assumed.  Types of client: Workalcholic and sleepers [Barbara Sigmod 94]  Strategies:  Amnestic Terminals: broadcast only the identifiers of the items that changed since the last invalidation report abort T, if x є RS(T) appears in the invalidation report  Timestamp Strategy: broadcast the timestamps of the latest updates for items that have occurred in the last w seconds. abort T, if ts(x) > tso(T)  Signature Strategy: broadcast signatures. A signature is a compressed checksum similar to the one used for file comparison.

6/30/2015 01:07 60 Consistency and Currency  Only committed data are included in the broadcast  Does a client read current and consistent data?  Currency interval is the fraction of bcycle that updates are reflected  Span(T) is the # of currency intervals from which T read data  if Span(T) = 1, the T is correct (read consistent data) else ?... several consistency models

6/30/2015 01:07 61 Consistency Criteria  Latest value: clients read the most recent value of a data item [Garcia-Molina TODS82, Acharya VLDB96]  Serializability: Certification reports [Barbara ICDCS97]  Update consistency: clients commit of their reads are not invalidated – read mutually consistent data  F-Matrix method [Shanmugasundaram SIGMOD99]  2-level serializability: Each client is serializable with respect to the server  SGT method [Pitoura&Chrysanthis ICDS99]  Multiversion [Pitoura&Chrysanthis VLDB99]

6/30/2015 01:07 62 VLDB 1999 10 begin (first read) first invalidationcommit Multiversioning with invalidation Invalidation Versioning Multiversioning T’s lifetime Currency in Multiversion Schemes

6/30/2015 01:07 63 Adaptive Hybrid Broadcast  Cycle-based, bidirectional hybrid broadcast server  Issues:  Dynamic computation of bandwidth allocated to each broadcast mode  Dynamic classification of data items (periodic vs. on-demand)  Scheduling periodic and on-demand broadcasts

6/30/2015 01:07 64 An Approach  After each broadcast cycle, items classified as periodic or on-demand, depending on bandwidth savings expected  Periodic broadcast occupies up to BWThreshold  Periodic broadcast program is computed to satisfy all deadlines of periodic data  On-demand broadcast uses on-line EDF (Earliest Deadline First) algorithm + batching

6/30/2015 01:07 66 Database Systems Issues  Issues  Battery power restrictions  Resource restrictions  Bandwidth restrictions and variability  Frequent/planned disconnections  Solutions  Power conservation techniques  Wireless broadcast, broadcast disks  Disconnected operations – Hoarding, caching, prefetching, consistency management  Programmer Interface for Application-aware Adaptation.

6/30/2015 01:07 67 Disconnected Operations  Issues:  Cache misses are more expensive in mobile environments.  Data availability for disconnected operation  Data consistency given that global communication is costly  Autonomy vs. Consistency  Solutions:  Caching  Prefetching  Hoarding  Eventual consistency – Assumption: simultaneous sharing other than read is rare.  Update conflict detection/resolution

6/30/2015 01:07 68 Caching  What to cache?  Entire files, directories, tables, objects  Portions of files, directories, tables, objects  When to cache? Is simple LRU sufficient?  LRU captures an aspect of temporal locality  Predictive/semantic caching: based on the semantics distance between data/request E.g., clustering of queries [Ren 99]

6/30/2015 01:07 69 Prefetching  Online strategy to improve performance  prepaging  prefetching of file  prefetching of database objects  What to fetch?  access tree (semantic structure)  probabilistic modeling of user behavior  Old idea that can be used during network idle times  Combine delayed writeback and prefetch

6/30/2015 01:07 70 Hoarding  Planned and Accidental disconnections are not considered failures.  New idea - Hoarding: a technique to reduce the cost of cache misses during disconnection. That is, load before disconnect and be ready.  How to do hoarding?  user-provided information (client-initiated disconnection) –explicitly specify which data –Implicitly based on the specified application  access structured-based (use past history) E.g., tree-based in file systems, access paths (joins) in DBs

6/30/2015 01:07 71 Hoarding in DB Systems  Granularity of Hoarding  RDBMS: ranges from tables, set of tables, whole relations  OO & OR DBMS: objects, set of objects or class  Hoard by issuing queries or materialized views  User may explicit issue hoarding queries E.g., Create View with Update-On clause [Lauzac 98] OO query to describe hoarding profiles [Gruber 94]  History of past references both queries and data objects  Hoard Keys - an extended database organization [Badrinath 98] –hoard keys are used to partition a relation in disjoint logical horizontal fragments

6/30/2015 01:07 72 Processing the Log  What information to keep in the log for effective reintegration and log optimization?  Data values, timestamps, operations  Goal: Keep the log size small to  Save memory  Reduce cost for update propagation and reintegration  When to optimize the log  Incrementally each time a new operation is added  Before propagation or integration  Optimizations are system specific  E.g., keep last write record, drop records of inverted operations

6/30/2015 01:07 73 Cache Coherence/Data Consistency  "Lazy" or weak consistency promises high availability  Consider some conflicts (e.g., write-write conflicts)  Read-any/Write-any  Other schemes are costly:  Pessimistic replication schemes/Quorum schemes  Server-initiated callbacks for cache invalidation (e.g., Leases).  Optimistic replication schemes  System support for  detection of conflicts: version vector, timestamps  automatic resolution or manual resolution (tools)

6/30/2015 01:07 74 Techniques to Increase Autonomy  Mobile Database Consistency  When a mobile database M shares a data item with another database D, it is involved in a global integrity constraint C.  Transactions on both M and D may suffer unbounded and unpredictable delays - No local commitment.  What about localizing the constraints – no global constraints?  Localization: reformulates C so that M accepts a local constraint C’ instead  Local transactions remain local.  When C’ is violated at a node, it requests the others for re-localization, i.e., a dynamic readjustment of C’. –No need for a distributed transaction. –No inconsistency from concurrent requests

6/30/2015 01:07 75 Localization of Constraints  Simple Example :  Let x and y be two data items at two nodes.  C = J.x + K.y > D is a global constraint.  Localization yields two local constraints: x > L1 and y > L2 where L1 and L2 are constants chosen such that J.L1 + K.L2 > D  Re-localization: L1, L2 can be changed: node y increases L2 before node x decreases L1

6/30/2015 01:07 76 Localization Methods  Escrowing: Logically partitions aggregated items  Escrow transactions [O’Neil 86]  Demarkation protocol [Barbara 91]  Geormetric Method [Mazumdar 99]: Enhanced Escrowing  It tackles quadratic inequalities  Fragmentation [Walborn 95]: Physically partitions item with constraints localized within the individual fragments  Fragmentable objects: fragments are merged to the originating position  Reorderable Objects: fragments can be re-organized during the merging

6/30/2015 01:07 77 Two-tier Transaction Models o Tentatively Committed Transactions  Transactions tentatively commit on a mobile unit  Make their results locally visible leading to abort dependencies  Certification based on application or system defined criteria  invalidated trans. are aborted, reconcile, or compensated  Isolation-Only Transactions [Lu 94]  First-class transactions for connected operations –immediately commit at the server, globally serializable  Second-class transactions for disconnected operations –tentatively commit, locally serializable, no failure atomicity –validation criteria: global serializability, global certifiability –invalidated trans. are aborted, reexecuted, or compensated.

6/30/2015 01:07 78 Two-tier transaction Models  Two-tier Replication [Gray 95]  Base transactions and Tentative transactions (disconnected)  Upon reconnection, tentative transactions are reprocessed as base transactions on master data version  Application semantics are used to increase concurrency and acceptance (e.g., commutative operations ) o (Mobile) Escrow Transactions  Transactions are validated locally by localizing constraints  Local commitment ensures global commitment

6/30/2015 01:07 79 Mobile Transactions  Distributed transactions involving both mobile and fixed hosts.  Traditional approaches are too restrictive.  Mobile Open Nested Transactions [Chrysanthis 93] Goals: sharing of partial results while in execution, maintaining computation state on a fixed host, moving transactions on/off a mobile host and across fixed hosts.  Components: Atomic transactions, Compensatable transaction, Reporting transactions and Co-transactions.  Properties: Component isolation, semantic atomicity Components may commit/abort independently

6/30/2015 01:07 80 Mobile Transactions  Kangaroo Transactions [Dunham 97]  Transaction relocation is achieved by splitting the transaction during hand-off. One Joey transaction per cell. o The Clustering Model [Pitoura 95]  A distributed database is divided into weak and strict clusters  Data in a cluster are mutually consistent  Inconsistency between clusters is bounded and resolved by merging them either –during transaction commitments, or –when connectivity improves  A mobile transaction is decomposed into Strict and Weak transactions based on consistency requirements  Only strict transactions ensure durability and currency of reads

6/30/2015 01:07 81 Failure Recovery  Emphasis has been on recording global checkpoints  Periodically store the state of a distributed application with mobile components.  DB Failure Recovery: Logging and checkpointing  Failures can be soft or hard  Soft failure can be recovered from the locally stored log and checkpoint  Hard failure require hard checkpoints stored in the fixed network.  Issues:  When to propagate the log and create a hard checkpoint?  Where to store hard checkpoints to speed up recovery and reduce its cost?

6/30/2015 01:07 82 Database Interface  Desirable features:  Semantic simplicity: formulation of queries without special knowledge  Interaction with a pointing device  Disconnected query specification o QBI (Query By Icons) [Massari-Chrysanthis 95]  Iconic language requiring minimum typing  Semantic data model that hides details  Metaquery tools for query formulation during disconnections

6/30/2015 01:07 84 Mobile Access to the Web  Three-tier Architectures: Client - Web Server - Data Server  Web Server can act like a server-side agent  Prefetching at its cache can hide some latency  Scripts at the Web server can perform user-specified filtering and processing.  Most solutions use a Web proxy to avoid any changes to the browsers and servers.  Pythia [Fox96]  Mobile Browser (MOWSER) [Joshi 96] –Distillation: highly lossy, real-time,datatype specific compression that preserves semantic content  WebExpress [Housel 97]

6/30/2015 01:07 85 WebExpress  Utilizes the C-I-S Model  Goals: reduce traffic volume and reduce latency  Intercept any http request and perform four optimizations:  Caching at both CSA & SSA of graphics and html objects  Differencing: only changes are communicated  Long-live TCP/IP Connection: CSA & SSA use a single TCP connection  Header reduction: SSA includes the required browser capabilities. They are not sent by the CSA.  While disconnected (off-line mode) uses CSA cache

6/30/2015 01:07 86 Advances in Mobile Web Servers  W4 for Wireless WWW [bartlett 94]: Mosaic on PDA  Dynamic Documents: Tcl scripts that execute within the mobile browser to customize the html documents  Dynamic URLs [Mobisaic 94]: They support mobile web servers and work with active pages.  IPiC [Shrinivasan 99]: A match head sized web server

6/30/2015 01:07 87 Mobility in Workflows  Workflows are automated business processes.  involve coordinated execution of multiple long- running tasks or activities  Workflow system coordinates the workflow execution.  Processing entities (clients) are where the activities are executed and can be mobile. disconnections among procesing entities (clients)

6/30/2015 01:07 88 Workflow Disconnected Operations A pessimistic approach: Exotica  Prior to disconnection, each client:  reserves the activities it plans to work by locking  hoards the relative to the activities data (requests from the server the input containers of the activities)  During disconnection,  stores results in its local stable memory  Upon reconnection,  the results are reported back to the server

6/30/2015 01:07 89 Mobile Agents in Workflows  A Mobile Agent Workflow Model: INCAS  No centralized workflow server  Each workflow process is model as a mobile agent called Information Carrier (INCA). Each INCA  encapsulates the private data of the workflow  carries a set of rules that control the flow between the activities of the INCA computation  maintains the history (log) of its execution  Each INCA is initially submitted to a procesisng entity (client) and roams among processing entities to achieve its goal

6/30/2015 01:07 91 Mobility Middleware in the Market  Most middleware market are based on TCP/IP and socket- oriented connections  Wireless-friendly TCP versions have been proposed but no major products adopted it  Microsoft’s Remote Access supports cellular communication by integrating Shiva’s PPP suite  Shiva’s PPP (Point-to-Point protocol) suit provide a remote access client to either wired or mobile servers  E.g., mobile clients can access Tuxedo transaction services  MobileWare Office Server: An agent-based middleware that supports Lotus Notes, Web access, database replication, etc.  Connection profiles, checkpointing,compression, security

6/30/2015 01:07 92 State of Mobile DB Industry  Sybase SQL Remote (Sybase SQL AnyWhere)  MobiLink: Centralized model to control replication  Application-specific bi-directional synchronization using scripts  UltraLite: in-memory dbms (50KB)  ORACLE  Oracle Mobile Agents middleware  Oracle 8 Lite: supports bi-directional replication between a client and a server (50-750KB)  Oracle Replication Manager: supports replication across multiple servers based on the peer-to-peer model  MS SQLServer  Merge replication and conflict resolution  Alternative clients: Outlook and MS ACCESS  IBM DB2 Everywhere (100KB)

6/30/2015 01:07 93 Case Study: Coda  Client-Server System with two classes of replication w.r.t. consistency  Disconnected vs. Weakly connected  Hoarding, Caching/Server callback, No Prefetching  During connections: Allows AFS clients (Venus) to hoard files.  hierarchical, prioritized cache management  equilibrium.  track dependencies, bookmarks  During disconnections: Venus acts as (emulates) a server  generates (temp) fids, services request to hoarded files.  On reconnection, Venus integrates locally changed files to servers.  Considers only write-write conflicts - no notion of atomicity  User conflict resolution/ Application-aware adaptation [Odyssey]  Use optimistic replication technique

6/30/2015 01:07 94 Coda Client Space Management  Space requirements - 10MB  space for hoarding applications  space use during Emulation (in particular logging)  space for Recoverable Virtual Memory (cache directory, symbolic link, status of block etc.)  Free disk space techniques  compression of file cache and RVM (space vs. computation time)  abort updates made by users (reduce log space)  allow file cache and RVM to be copy to flush cards/floppy disks.

6/30/2015 01:07 95 Case Study: Consistency in Bayou  A bottom-up approach to specific design problems  more distributed than coda, more emphasis on "small" clients  Key features:  read-any/write-any to enhance availability  anti-entropy protocol for eventual consistency  dependency checks on each write –dependency set –If queries (run at server) do return the expected results –Application-specific resolution of update conflicts  Primary server to commit writes and set order  Session consistency guarantees  How effective is anti-entropy?

6/30/2015 01:07 96 Anti-entropy Protocol  Server propagates write among copies.  Eventual all copies "converge" towards the same state.  Eventual reach identical state if no new updates.  Pair-to-peer anti-entropy  each server periodically selects another server  exchange writes and agree on the performed order  reach identical state after performing the same writes in the same order.

6/30/2015 01:07 97 Case Study: Rover  Rover [Joseph 97] provides an environment for the development of mobile applications  Applications are split into client and server part communicating with Queued RPCs  Application code and data are encapsulated within Relocatable Dynamic Objects (RDOs)  Access Managers at client and server handle RDOs  Client’s operational log is lazily transfer to the server  Disconnections are supported by the local cache  Some support for primary copy, optimistic consistency

6/30/2015 01:07 98 Case Study: Pro-Motion  Pro-Motion [Chrysanthis 97] is designed for the development of mobile database applications.  It shares similar architecture as Rover with a multi-tier C-I-S model.  Compact is the unit of caching and hoarding  It encapsulates cached data, methods, consistency rules and obligations (e.g., deadlines).  Supports both tentatively committed transactions and two-tier replication.

6/30/2015 01:07 99 Case Study: Rome  Rome [Fox 99] goals is the timely and in context delivery of information  Information should be received when and where it is needed  Its fundamental building block are the triggers:  pieces of data bundled with contextual information  Condition: (location  R)  (time  t)  action  It is similar to active databases but with decentralized management  It provides an extensible framework and building blocks leveraging on internet service.

6/30/2015 01:07 100 Unsolved Problems  Integration and evaluation of algorithms with applications  Broadcast disks  Information update/consistency and data temporal coherence - meet time constraints of requests  Relation between server broadcasting and client caching.  Multiple broadcast channels and multiple database access  Efficient, scalable, adaptive mechanisms  Location handling  Trigger management  Programmer Interface for Application-aware adaptation  Data fidelity vs. consistency  Semantic consistency needs metadata/requirements  Multimedia and QoS

6/30/2015 01:07 101 To Recap Mobile and wireless computing attempts to deliver today’s and tomorrow’s applications on yesterday’s hardware and communication infrastructure!

6/30/2015 01:07 102 Summary  need for mutual consistency + currency  need efficient, scalable, adaptive mechanisms  semantic consistency needs metadata  temporal consistency needs user req.  weak consistency with caches  many open issues

6/30/2015 01:07 103 Broadcast  Broadcast as an air-cache for storing frequently requested data  Continoulsy adjust the broadcast content to match the database hot-spot  How? By observing the broadcast misses - requests for data not on the broadcast

6/30/2015 01:07 104 Outline  broadcast environments  issues in reading consistent data -- on time  semantic consistency –correctness criteria –mechanisms for disseminating (control) data –exploiting caches  temporal consistency

6/30/2015 01:07 105 Client-Server Communication Model  Asymmetric communication environments  Server broadcasts data to clients using high bandwidth broadcast links  Clients listen to the broadcast to fetch data  Clients communicate with the server using low bandwidth upstream links  Update handling  Clients send update data to server  Server resolves update conflicts, commits updates, and broadcasts updates to clients

6/30/2015 01:07 106 Semantic Consistency R(x)R(y)R(z) time (broadcast cycles) Are x, y, and z mutually consistent? TrBegin TrEnd Update x and z

6/30/2015 01:07 107 Time Constrained Broadcasts

6/30/2015 01:07 108 Temporal Consistency  Meet data temporal coherence  improve currency of data read by clients  attach validity interval for each broadcast data object  Meet time constraints (deadlines) of requests

6/30/2015 01:07 109 Outline  broadcast environments  issues in reading consistent data on time  semantic consistency –correctness criteria –mechanisms for disseminating (control) data –exploiting caches  temporal consistency

6/30/2015 01:07 110 Serializability in Bcast Env.  Serializability: a global property  dynamic conflict resolution => excessive comm. –e.g., locking: acquiring read locks by client transactions server swamped with lock requests client uses precious uplink bandwidth  avoid potential conflicts – clients must be conservative unilaterally disallow certain correct executions »unnecessary aborts

6/30/2015 01:07 111 Serialization Orders C4C4 W4(y)W4(y) ServerW2(x)W2(x) C2C2 Client A R1(y)R1(y) R1(x)R1(x) R3(x)R3(x) R3(y)R3(y) Client B T 2 T 4 T4T1T2T4T1T2 T2T3T4T2T3T4 But, global history is not serializable

6/30/2015 01:07 112 Serializability? all read-only transactions 1. required to see the same serial order of update transactions -- even if executing at different clients 2. required to be serializable w.r.t. all the update transactions -- even if updates do not affect the values read unnecessary and inappropriate

6/30/2015 01:07 113 Broadcast Data Requirements Mutual consistency -- server maintains mutually consistent data -- clients read mutually consistent data Currency -- clients see data that is current

6/30/2015 01:07 114 A Sufficient Criterion All update transactions are serializable. Each read-only transaction is serializable with respect to the update transactions it (directly or indirectly) reads from. C4C4 W4(y)W4(y) Server W2(x)W2(x) C2C2 Client A R1(y)R1(y) R1(x)R1(x) R3(x)R3(x) R3(y)R3(y) Client B T2T4T2T4 T4T1T2T4T1T2 T2T3T4T2T3T4

6/30/2015 01:07 115 Implications read-only transactions need not contact the server. => addresses the primary problems with serializability If clients know update schedule

6/30/2015 01:07 116 Summary  need for mutual consistency + currency  need efficient, scalable, adaptive mechanisms  semantic consistency needs metadata  temporal consistency needs user req.  weak consistency with caches  many open issues

6/30/2015 01:07 117 Field Computing

6/30/2015 01:07 118 Assumptions for Broadcast Disks  Wireless data broadcasting can be viewed as "storage on the air".  Periodic broadcast - broadcast cycles or bcycles  Bucket: logical unit of broadcast  Each bucket has an address or sequence number within the broadcast.  Data changes often  Each successive broadcast may differ in size and content  No updates during a particular broadcast.  Client has no prior knowledge of the structure or content of the broadcast.  Clients are interested in fetching a particular record identified by a key.  Access time: avg time elapsed between the beginning of the search for an item to the reading of it from the broadcast channel  Listening/Tuning time: the amount of time spent listening to the broadcast channel

6/30/2015 01:07 119 Access protocol  Index buckets hold the directory, data buckets hold data.  User tunes in to find out when a needed index bucket is broadcasted.  Synchronize by accessing a pointer that tells the user when to tune in for the data.  After you synchronize you must access the data in the same broadcast.  Tune in to the data at the right time.

6/30/2015 01:07 120 (1,M) Indexing  We broadcast the index M times during one version of the data.  After broadcasting 1/M of the file we broadcast the index.  ~ All buckets have the offset to the beginning of the next index segment.  Data access protocol for record with key Q  Listen to current bucket.  Read the offset.  Go to sleep till the next index segment  From the index determine when Q arrives.  (May have to follow several levels of indexes.)  Tune in again to pick up record.

6/30/2015 01:07 121 Distributed Indexing  Goal: Let's cut down on the replication of index material  Solution: It is sufficient to broadcast only the portion of the index which describes the data segment that follows. No replication.  Problem with the no replication approach.  User can't determine when relevant indexing is coming!  Number of probes grows linearly with number of levels in tree, and  the number of pointers in an index bucket. Very bad.  New Solution: Distributed indexing. Divide the index into:  replicated top l levels  non-replicated bottom 4-l levels  Result: * Index overhead vs. + tuning time

6/30/2015 01:07 122 Flexible Indexing  broadcast divided into p data segments.  data items are assumed sorted  a control index is associated with each segment  binary control index to determine the data segment  local index to locate the specific item within the segment

6/30/2015 01:07 123 Mobility  bandwidth restrictions and variability  bursty network activity - during connections  handling disconnections (planned failures?)  caching strategies  managing inconsistencies

6/30/2015 01:07 1 Mobile and Wireless Database Access for Pervasive Computing Panos K. Chrysanthis University of Pittsburgh & Carnegie Mellon University.

Similar presentations

Presentation on theme: "6/30/2015 01:07 1 Mobile and Wireless Database Access for Pervasive Computing Panos K. Chrysanthis University of Pittsburgh & Carnegie Mellon University."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

6/30/2015 01:07 1 Mobile and Wireless Database Access for Pervasive Computing Panos K. Chrysanthis University of Pittsburgh & Carnegie Mellon University.

Similar presentations

Presentation on theme: "6/30/2015 01:07 1 Mobile and Wireless Database Access for Pervasive Computing Panos K. Chrysanthis University of Pittsburgh & Carnegie Mellon University."— Presentation transcript:

Similar presentations

About project

Feedback