List of German expressions in English: Difference between revisions

Revision as of 02:36, 24 January 2014

In computer science, a timestamp-based concurrency control algorithm is a non-lock concurrency control method. It is used in some databases to safely handle transactions, using timestamps.

Operation

Assumptions

Every timestamp value is unique and accurately represents an instant in time.
No two timestamps can be the same.
A higher-valued timestamp occurs later in time than a lower-valued timestamp.

Generating a Timestamp

A number of different ways have been used to generate timestamp

Use the value of the system's clock at the start of a transaction as the timestamp.
Use a thread-safe shared counter that is incremental at the start of a transaction as the timestamp.
A combination of the above two methods.

Formal

Each transaction ( $T_{i}$ ) is an ordered list of actions ( $A_{i x}$ ). Before the transaction performs its first action ( $A_{i 1}$ ), it is marked with the current timestamp, or any other strictly totally ordered sequence: $T S (T_{i}) = N O W ()$ . Every transaction is also given an initially empty set of transactions upon which it depends, $D E P (T_{i}) = []$ , and an initially empty set of old objects which it updated, $O L D (T_{i}) = []$ .

Each object $(O_{j})$ in the database is given two timestamp fields which are not used other than for concurrency control: $R T S (O_{j})$ is the time at which the value of object was last used by a transaction, $W T S (O_{j})$ is the time at which the value of the object was last updated by a transaction.

For all $T_{i}$ :

For each action

A_{i x}

:

If

A_{i x}

wishes to use the value of

O_{j}

:

If

W T S (O_{j}) > T S (T_{i})

then abort (a more recent thread has overwritten the value),

Otherwise update the set of dependencies

D E P (T_{i}) . a d d (W T S (O_{j}))

and set

R T S (O_{j}) = \max (R T S (O_{j}), T S (T_{i}))

;

If

A_{i x}

wishes to update the value of

O_{j}

:

If

R T S (O_{j}) > T S (T_{i})

then abort (a more recent thread is already relying on the old value),

If

W T S (O_{j}) > T S (T_{i})

then skip (the Thomas Write Rule),

Otherwise store the previous values,

O L D (T_{i}) . a d d (O_{j}, W T S (O_{j}))

, set

W T S (O_{j}) = T S (T_{i})

, and update the value of

O_{j}

.

While there is a transaction in

D E P (T_{i})

that has not ended: wait

If there is a transaction in

D E P (T_{i})

that aborted then abort

Otherwise: commit.

To abort:

For each

(o l d O_{j}, o l d W T S (O_{j}))

in

O L D (T_{i})

If

W T S (O_{j})

equals

T S (T_{i})

then restore

O_{j} = o l d O_{j}

and

W T S (O_{j}) = o l d W T S (O_{j})

Informal

Whenever a transaction starts, it is given a timestamp. This is so we can tell which order that the transactions are supposed to be applied in. So given two transactions that affect the same object, the transaction that has the earlier timestamp is meant to be applied before the other one. However, if the wrong transaction is actually presented first, it is aborted and must be restarted.

Every object in the database has a read timestamp, which is updated whenever the object's data is read, and a write timestamp, which is updated whenever the object's data is changed.

If a transaction wants to read an object,

but the transaction started before the object's write timestamp it means that something changed the object's data after the transaction started. In this case, the transaction is canceled and must be restarted.
and the transaction started after the object's write timestamp, it means that it is safe to read the object. In this case, if the transaction timestamp is after the object's read timestamp, the read timestamp is set to the transaction timestamp.

If a transaction wants to write to an object,

but the transaction started before the object's read timestamp it means that something has had a look at the object, and we assume it took a copy of the object's data. So we can't write to the object as that would make any copied data invalid, so the transaction is aborted and must be restarted.
and the transaction started before the object's write timestamp it means that something has changed the object since we started our transaction. In this case we use the Thomas Write Rule and simply skip our write operation and continue as normal; the transaction does not have to be aborted or restarted
otherwise, the transaction writes to the object, and the object's write timestamp is set to the transaction's timestamp.

Recoverability

For an explanation of the terms recoverable (RC), avoids cascading aborts (ACA) and strict (ST) see Schedule (computer science).

Note that timestamp ordering in its basic form does not produce recoverable histories. Consider for example the following history with transactions $T_{1}$ and $T_{2}$ :

W_{1} (x) R_{2} (x) W_{2} (y) C_{2} R_{1} (z) C_{1}

This could be produced by a TO scheduler, but is not recoverable, as $T_{2}$ commits even though having read from an uncomitted transaction. To make sure the it produces recoverable histories, a scheduler can keep a list of other transactions each transaction has read from, and not let a transaction commit before this list consisted of only committed transactions. To avoid cascading aborts, the scheduler could tag data written by uncommitted transactions as dirty, and never let a read operation commence on such a data item before it was untagged. To get a strict history, the scheduler should not allow any operations on dirty items.

Implementation Issues

Timestamp Resolution

This is the minimum time elapsed between two adjacent timestamps. If the resolution of the timestamp is too large (coarse), the possibility of two or more timestamps being equal is increased and thus enabling some transactions to commit out of correct order. For example, assuming that we have a system that can create one hundred unique timestamps per second, and given two events that occur 2 milliseconds apart, they will probably be given the same timestamp even though they actually occurred at different times.

Timestamp Locking

Even though this technique is a non-locking one, in as much as the Object is not locked from concurrent access for the duration of a transaction, the act of recording each timestamp against the Object requires an extremely short duration lock on the Object or its proxy.

@@ Line 1: / Line 1: @@
-The name of the writer happens to be Adrianne Quesada. Managing consumers is what she does in her day [https://www.vocabulary.com/dictionary/writing writing] but she's always wanted her own [http://Www.Dailymail.Co.uk/home/search.html?sel=site&searchPhrase=business business]. Her husband doesn't like the idea the way she carries out but what she especially likes doing is in order to bake but she's pondering on starting something fresh, new. Vermont will where her house is. Her husband and her maintain a website. You might wish to check it out: http://prometeu.net<br><br>my page [http://prometeu.net clash of clans unlimited gems hack]
+{{Multiple issues|unreferenced = June 2007|disputed = April 2012|cleanup = April 2012}}
+In [[computer science]], a '''timestamp-based concurrency control''' algorithm is a [[non-lock concurrency control]] method. It is used in some [[database]]s to safely handle transactions, using [[timestamp]]s.
+==Operation==
+===Assumptions===
+* Every timestamp value is unique and accurately represents an instant in time.
+* No two timestamps can be the same.
+* A higher-valued timestamp occurs later in time than a lower-valued timestamp.
+===Generating a Timestamp===
+A number of different ways have been used to generate timestamp
+* Use the value of the system's clock at the start of a transaction as the timestamp.
+* Use a thread-safe shared counter that is incremental at the start of a transaction as the timestamp.
+* A combination of the above two methods.
+===Formal===
+Each transaction (<math>T_i</math>) is an ordered list of actions (<math>A_{ix}</math>). Before the transaction performs its first action (<math>A_{i1}</math>), it is marked with the current [[timestamp]], or any other [[total order|strictly totally ordered]] sequence: <math>TS(T_i) = NOW()</math>. Every transaction is also given an initially empty set of transactions upon which it depends, <math>DEP(T_i) = []</math>, and an initially empty set of old objects which it updated, <math>OLD(T_i) = []</math>.
+Each [[Object (computer science)|object]] <math>(O_j)</math> in the database is given two timestamp fields which are not used other than for concurrency control: <math>RTS(O_j)</math> is the time at which the value of object was last used by a transaction, <math>WTS(O_j)</math> is the time at which the value of the object was last updated by a transaction.
+For all <math>T_i</math>:
+:For each action <math>A_{ix}</math>:
+::If <math>A_{ix}</math> wishes to use the value of <math>O_j</math>:
+:::If <math>WTS(O_j) > TS(T_i)</math> then '''abort''' (a more recent thread has overwritten the value),
+:::Otherwise update the set of dependencies <math>DEP(T_i).\mathrm{add}(WTS(O_j))</math> and set <math>RTS(O_j) = \max(RTS(O_j), TS(T_i))</math>;
+::If <math>A_{ix}</math> wishes to update the value of <math>O_j</math>:
+:::If <math>RTS(O_j) > TS(T_i)</math> then '''abort''' (a more recent thread is already relying on the old value),
+:::If <math>WTS(O_j) > TS(T_i)</math> then '''skip''' (the [[Thomas Write Rule]]),
+:::Otherwise store the previous values, <math>OLD(T_i).\mathrm{add}(O_j, WTS(O_j))</math>, set <math>WTS(O_j) = TS(T_i)</math>, and update the value of <math>O_j</math>.
+:While there is a transaction in <math>DEP(T_i)</math> that has not ended: '''wait'''
+:If there is a transaction in <math>DEP(T_i)</math> that aborted then '''abort'''
+:Otherwise: '''commit'''.
+To '''abort''':
+:For each <math>(\mathrm{old}O_j, \mathrm{old}WTS(O_j))</math> in <math>OLD(T_i)</math>
+::If <math>WTS(O_j)</math> equals <math>TS(T_i)</math> then restore <math>O_j = \mathrm{old}O_j</math> and <math>WTS(O_j) = \mathrm{old}WTS(O_j)</math>
+===Informal===
+Whenever a transaction starts, it is given a timestamp. This is so we can tell which order that the transactions are supposed to be applied in. So given two transactions that affect the same object, the transaction that has the earlier timestamp is meant to be applied before the other one. However, if the wrong transaction is actually presented first, it is aborted and must be restarted.
+Every object in the database has a '''read timestamp''', which is updated whenever the object's data is read, and a '''write timestamp''', which is updated whenever the object's data is changed.
+If a transaction wants to read an object,
+* but the transaction started ''before'' the object's '''write timestamp''' it means that something changed the object's data after the transaction started. In this case, the transaction is canceled and must be restarted.
+* and the transaction started ''after'' the object's '''write timestamp''', it means that it is ''safe'' to read the object. In this case, if the transaction timestamp is after the object's '''read timestamp''', the read timestamp is set to the transaction timestamp.
+If a transaction wants to write to an object,
+* but the transaction started ''before'' the object's '''read timestamp''' it means that something has had a look at the object, and we assume it took a copy of the object's data. So we can't write to the object as that would make any copied data invalid, so the transaction is aborted and must be restarted.
+* and the transaction started ''before'' the object's '''write timestamp''' it means that something has changed the object since we started our transaction. In this case we use the [[Thomas Write Rule]] and simply skip our write operation and continue as normal; the transaction does not have to be aborted or restarted
+* otherwise, the transaction writes to the object, and the object's '''write timestamp''' is set to the transaction's timestamp.
+==Recoverability==
+For an explanation of the terms '''recoverable''' (RC), '''avoids cascading aborts''' (ACA) and '''strict''' (ST) see [[Schedule (computer science)]].
+Note that timestamp ordering in its basic form does not produce recoverable histories. Consider for example the following history with transactions <math>T_1</math> and <math>T_2</math>:
+:<math>W_1(x)\;R_2(x)\;W_2(y)\;C_2\;R_1(z)\;C_1</math>
+This could be produced by a TO scheduler, but is not recoverable, as <math>T_2</math> commits even though having read from an uncomitted transaction. To make sure the it produces recoverable histories, a scheduler can keep a list of other transactions each transaction has ''read from'', and not let a transaction commit before this list consisted of only committed transactions. To avoid cascading aborts, the scheduler could tag data written by uncommitted transactions as ''dirty'', and never let a read operation commence on such a data item before it was untagged. To get a  strict history, the scheduler should not allow any operations on dirty items.
+==Implementation Issues==
+===Timestamp Resolution===
+This is the minimum time elapsed between two adjacent timestamps. If the resolution of the timestamp is too large (coarse), the possibility of two or more timestamps being equal is increased and thus enabling some transactions to commit out of correct order. For example, assuming that we have a system that can create one hundred unique timestamps per second, and given two events that occur 2 milliseconds apart, they will probably be given the same timestamp even though they actually occurred at different times.
+===Timestamp Locking===
+Even though this technique is a non-locking one, in as much as the Object is not locked from concurrent access for the duration of a transaction, the act of recording each timestamp against the Object requires an extremely short duration lock on the Object or its proxy.
+==See also==
+* [[Multiversion concurrency control]]
+* [[Timestamping (computing)]]
+[[Category:Concurrency control]]
+[[Category:Concurrency control algorithms]]
+[[Category:Transaction processing]]

List of German expressions in English: Difference between revisions

Revision as of 02:36, 24 January 2014

Contents

Operation

Assumptions

Generating a Timestamp

Formal

Informal

Recoverability

Implementation Issues

Timestamp Resolution

Timestamp Locking

See also

Navigation menu

List of German expressions in English: Difference between revisions

Revision as of 02:36, 24 January 2014

Operation

Assumptions

Generating a Timestamp

Formal

Informal

Recoverability

Implementation Issues

Timestamp Resolution

Timestamp Locking

See also

Navigation menu

Search