Messaging and Group Communication

Document Sample
Messaging and Group Communication Powered By Docstoc
					    Time Synchronization- related work

Time                In distributed systems       In distributed simulation   In distributed data
Synchronization                                                              management
approaches


•Conservative       •Cristian algorithm          •Parallel Discrete Event    •Data currency and t-bound
•Optimistic         •Berkley algorithm           Simulation                  queries
•Scaled real-time   •Lamport algorithm           •Distributed Interactive    •Temporal consistency
                    •Time Warp                   Simulation                  •Multi version concurrency
                    •SPEEDS                      •Aggregated Level           control – real only transactions
                                                 Simulation Protocol         •2-level serilizability
                    •Clock Synchronization       •High Level Architecture    •Current copy serilizability
                    -Network time protocol

                    •Time scale Transformation
                    -Client –server
                    -Time stamp synch
                    -Beacon node broadcast
                    -Light weight time
                    synchronization




1
  Duality- Serializability in HDBMS and simulation integration

Integration of HDBMSs [Refs]                            Simulation Integration
Integrating a number of pre-existing local database     Integration of pre-existing simulators
management systems
Transactions, transaction programs                      Events, chunk of events

Local transactions: execute at single site              Internal events: process internally at a simulator

Global transactions: may execute at more than one       External events: may read/update some shared data
site

Local data items: the set of data items at a site       Local data items: the set of data items at a simulator

Global data items: data items at different site         Shared data items: data items shared between
between which integrity constrains are introduced as    different simulators (between them constrains are
a result of integration                                 introduced as a result of integration)
Allow to access data residing at multiple sites while   Allow to access data at multiple simulators while
preserving the local autonomy of various sites          preserving the local autonomy of different simulators
No assumption about the nature of local                 No assumption about the nature of local events in
transactions                                            the simulators
Local sites can follow any concurrency control          Internal events in simulators can follow any
protocol                                                time/data management mechanism
Local transactions execute out of the control of GTM    Internal events execute out of the control of MS (Meta-
(Global Transaction Manager)                            level synchronizer)
Different Solutions to HDBMSs



 1. Weakening autonomy by placing restrictions on local
    databases
    But our main goal is to preserve the autonomy of simulators
 2. Enforcing serializability by using local conflicts
    How to have prepare-to-commit state in different simulators?
    Low concurrency and possibility of aborts
 3. Relaxing serilizability constraints by defining alternative
    notion of correctness
       Need to separate local and global data (which we already have
        in our model as local/shared data
2LSR- a solution to HDBMSs integration
 2LSR : to preserve database consistency in HDBMS models
 Trivial model:
    Local transactions only read/write local data items
    Global transactions only read/write global data items
 The global read model:
    Local transactions only read/write local data items
    Global transactions read/write global data items and read local data items
    If there is no integrity constraint between local and global data items, 2LSR is
      strongly correct.
 The local read model
    Local transactions read/write local data items and also read global data items
    Global transactions only read/write global data items
    If global transaction programs do not have value dependencies (execution of a
      global transaction at a site is independent of its execution at other sites)
2LSR (cont.)
 The global read write model
    Local transactions only read/write local data items
    Global transactions only read/write global data items and also read/write local
     data items
    If there is no integrity constraint between local and global data items, and
     transactions programs are fixed structured (their execution from any database
     state results in the same transaction)
 The global read/write and local read model
    Local transactions read/write local data items and also read global data items
    Global transactions only read/write global data items and also read/write local
     data items
    Global transaction programs have no value dependencies and there is no
     integrity constraint between local and global data items
Extend it to our work

 To me it sounds our model fits to the trivial model
 Trivial model:
   Local transactions only read/write local data items
   Global transactions only read/write global data items
 Our model:
   Local events only r/w local data items
   External events only r/w shared data items
 Not worked because we have the notion of time!
Real-time databases

 Refs. For 2-level serilizability:
     Ensuring Consistency in Multidatabases by Preserving Two-Level
      Serializability S.Mehrotra
     Non-serializable executions in heterogeneous distributed database
      systems by S.Mehrotra et al.
     Serializability in Multidatabases by R.Lawrence
 Then we look into Real time database: in addition to consistency
  constraints we have timing constraint for transactions
Data currency and t-bound queries [18]


 The currency requirement of the query: what update transactions
   should be reflected by the data read
 T-bound: Q can request that data it reads at least reflect all
   update transaction committed before time t.
 If t=current time: latest-bound queries.
 Solutions for processing t-bound queries: to keep a history
1. Keep a log of all update transactions
     Examine the log in reverse chronological order until the desired data
      are reconstructed
2. Keep the log for each item value
     Examine the log for the item
Consistency among independent data [24]


  Members of interdependent data are managed by different
   databases
  Consistency among independent data: Interdatabase constraints
  DEP(D): structural dependency- specifies the structural dependency
   among the members of interdependant data
  CON(D) - interdatabase constrains: a logical expression of three
   aspect: data state: Cd(D), operation: Co(D), time: Ct(D)
  CON(D) <- Ct(D)=2 hour ^ Co(D)=2
  Means all the members of CON(D) must converge after two hours
   since the previous convergence of the members if there have been
   at least two updates
  A special case: CON(D)<-Co(D) implies that the members of D
   should be consistent immediately after an update on any member
   of D has been performed
Consistency among independent data [24]- cont.

  A member of interdependent data can be in one of these states:
      Mutually inconsistent: if the associated eventual consistency constraint
       is violated
      Lagging: if the eventual consistency constraint holds but it does not
       reflect all the updates so far
      Current: if the members reflect all the updates performed so far
  Two types of transactions:
  Update transactions: those that update interdependent data
  Read only transactions: those that read interdependent data
  It is required that update transactions read data from the current
   member of the interdependent data
  However for read only transactions it is possible to have two levels
   of consistency:
      Strong read require reading only a current member of D
      Weak consistency allows reading a lagging member of D
  Synchronize updates on interdependent data: we might not need
   this since we have one updater
Consistency among independent data [24]- cont.

  Besides satisfying interdependent constraints, internal consistency
   constraints of interdependent data must also satisfied
  internal consistency constraints: the constraints among data items
   in the same database
  When interdependent data do not exist the consistency of database
   is maintained by the concurrency controller of the local database
  When interdependent data exists the local concurrency controller is
   not sufficient: an example
  Current copy serilizability notion to ensure the correctness of
   update transactions – I proved that our model is current copy
   seializable
Temporal consistency [tcd20]

  The corresponding real worlds object x: image x
  x is updated periodically by write-only transactions
  As a new value of x written, an old value of the image read by
   other transactions ages,
  So an image have multiple versions, Each version has a valid time
  Age of an image at time t in the ith period after its valid time is i-1
  The derived object: can be computed based on sample values of
   images taken at different times, so it can have versions: derived
   versions
  Dispersion of two data objects: the difference between their age
      age of x : at(x)   age of y: at(y) dt(x,y)= at(x)- at(y)
  Q: set of images and derived objects, Q is absolutely temporally
   consistent at time t if at(x) <=A for every x in Q where A is the
   absolute threshold (A>=0)
  Relatively temporally consistent: if dt(x,y)<=R for every two
   objects x and y, R is the relative threshold (R>=0)
Multi version concurrency control [tcd20,
mv19, 21]
  Version pool algorithm [19]
  Eliminating conflicts between distributed read only transactions and
   update transactions- reducing synchronization delays
  Real only transactions see semantically consistent snapshot of the
   database- so never have to be rolled back
  the database: a collection of segments. Each segment is a collection
   of consecutively numbered logical pages. There is a single common
   pool of pages: the version pool, which is used for storing the old
   versions of segment pages potentially needed by in-progress
   transactions
  For efficient implementation:
      Locating the various versions of a given data object
      Determining the appropriate version of each data object
      Garbage collecting dead object versions that are no longer needed by
       ongoing transactions
Multi version concurrency control [tcd20,
mv19, 21]
  For a database system whose concurrency control mechanism
   serializes update transactions: if a read-only transaction Tr satisfies
   Condition 1 and Condition 2 , then it will read a consistent snapshot
   of the database.
      Condition 1: A read-only transaction reads the output of transactions
       that are committed or transactions that will eventually commit
      Condition 2: If T belongs to the set of update transactions from which
       a read-only transaction Tr reads, and if T depends on T', then T' also
       must belong to the set of update transactions from which T, reads
Read only actions [20]

  Broadcast commit algorithm
  read-only actions can read old versions while new updates continue
   to run using the current version.
     An important issue in each case is how to manage versions: when must
      a version be kept, and when can an old version be thrown away?
  Each action is assigned a unique timestamp.
  Update action: The timestamp is when it commits
  Read-only actions: the timestamp for a read-only action is chosen
   when it begins
  Update actions are synchronized using ordinary two-phase locking
  When a read-only action with timestamp 3 attempts to read an
   object, the version of the object written by the action with the
   largest timestamp less than T is selected as the value to be
   returned by the read operation
Time validity interval

  Temporal Consistency – Time validity interval (TVI): the
   period in which the data object is considered to be temporally
   consistent
  vib(xi): the beginning of the validity interval of the ith version of
   data object x
  vie(xi) : the end of the validity interval
  the ith version of data object x is temporally consistent at time t if
   and only if vib(xi) ≤ t < vie(xi)
  Concurrency control protocols:
Temporal consistency- sensor data items[23]

  Start_time (xi) + VIx > current time
  Start_time (xi) is the creation time of the current version xi of data
   item x
  VIx is the validity interval of x
  how to provide the required data items for execution with minimum
   data transmission overhead in a wireless sensor system is still a
   challenge
Consistency among independent data [24]

  Quasi copy from the source copy
  A selection condition: how a quasi copy can be derived from a
   source copy
  A coherency condition: how much a quasi copy can be deviate from
   the source copy
Metrics

  Some metrics from transactions-papers, simulations papers:
 1. Worst and average blocking time
      Blocking time is the duration when a transaction is blocked to access
       the data. This data allows us to trace a source of temporal
       inconsistency.
 2. The total number of events versus simulation (execution) time
 3. Additional overhead versus number of events

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:5
posted:12/11/2011
language:
pages:19