VIEWS: 5 PAGES: 19 POSTED ON: 12/11/2011
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  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  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 - 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 - 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  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  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 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  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
"Messaging and Group Communication"