Access Protocol

The access protocol considers transactions over OWL data items and operations as in- troduced inSection 6.2.1to6.2.3and essentially follows the SI protocol [BBG+95]. The protocol enforces the following two rules:

1. Given an OWL KB W, a transaction Ti sees a snapshot of W from the point in time when Ti started – every new transaction is associated with a unique start- timestamp ts larger than any timestamp that has been created before (i.e., strictly monotonic). Both read and update operations are executed on this snapshot. Up- dates submitted by other transactions that started after Tiare invisible to Ti. 2. When Tiis ready to commit, it gets a commit-timestamp tclarger than any existing

start and commit-timestamp. Ti commits successfully only if there is no other committed transaction Tj whose commit-timestamp is within the interval [ts, tc] and if the change sets are disjoint δ(T_i) ∩δ(Tj) = ∅. Otherwise, Ti, Tjconflict and T_iwill be aborted. This is also referred to as first committer wins.

A transaction is said to be active starting form the point in time when it has been as- signed with tsuntil the point in time when it has been assigned with tc.

4_{Note that any order among transactions is legitimate provided that there are no dependencies among} them. If there are dependencies then it is assumed that an order is secured outside the KBMS.

5_{To be precise, serializability is usually defined over the so-called commit-projection of a schedule: a} schedule S0obtained from a schedule S by removing aborted and active transactions (i.e., S0contains the committed transactions of S only).

Observe that in this protocol add and delete operations need to be considered in or- der to determine whether a transaction can commit because they determine the content of the change sets δ(T_i), δ(T_j). This makes commit analysis similar to SI applied to the database read/write model. Recap, in the presence of the write operation the write-sets are required to be disjoint. Read operations are not included in commit analysis because every transaction operates on its isolated snapshot. Reads can therefore be executed at their commencement. From this last aspect we can draw an important conclusion: Un- der the standard SI protocol it is irrelevant what type of read operations are available. This is important insofar as it allows adding specific query-like read operations (e.g., list all concept inclusions, list all assertions about a given individual). Such additional read operations are important for implementing efficient KB querying support, as op- posed to mapping all reads to the basic read operation r(ψ), which can easily become

inefficient.

As a matter of the fact that the protocol is a MVCC mechanism (i.e., each transaction operates on its own snapshot), it is guaranteed that reads only present results of com- mitted transactions. However, SI is known to allow for schedules that are not conflict equivalent to some serializable schedule; that is, there are some concurrency anomalies that can occur with this protocol. We will resume and detail the discussion on which properties are ensured inSection 6.2.8. Example 6.2illustrates the situation of conflict- ing update transactions.

Example 6.2

This example models the famous concurrent execution of a bank transfer and a with- draw from one account involved in the transfer. Suppose a KBW that initially contains two OWL datatype assertions

ψ1 =DataPropertyAssertion(:balance :ACC1 2770)and

ψ2 =DataPropertyAssertion(:balance :ACC2 200),

representing knowledge about two accounts :ACC1 and :ACC2 having a balance of 2770 and 200, respectively (i.e., :ACC1 and :ACC2 are names of two distinct individ- uals, :balance is the name of a data property, and 2770 and 200 are number values). Transaction Twd shall withdraw an amount of 70 from :ACC1 and transaction Ttfshall transfer an amount of 100 from :ACC1 to :ACC2. This can be realized using the follow- ing sequence of operations per transaction

T_wd =r(ψ1) d(ψ1) a(ψ3)

T_tf =r(ψ1)r(ψ2) d(ψ1) d(ψ2) a(ψ4) a(ψ5) where ψ3, ψ4, ψ5would be

ψ3 =DataPropertyAssertion(:balance :ACC1 2700)

ψ4 =DataPropertyAssertion(:balance :ACC1 2600)

Clearly, any interleaving of Twd, Ttfsuch that tTwd

s <tTctf <tTcwd or tsTtf <tTcwd <tTctf

is not serializable; hence, according to the first committer wins rule, Ttfcommits in the first case, whereas Twd commits in the second.

Example 6.2 contains conflicting read-add-delete transactions. The conflict would be detected because the change sets are not disjoint δd(Twd) ∩δd(Ttf) = {d(ψ1)}. This remains the same even if the applications submitting Twd, Ttf would (magically) know the current balance of both accounts so that the reads r(ψ1), r(ψ2) do not appear (add- delete transactions), thus, the transactions still conflict.

Snapshots need to be created (for reads by other transactions) whenever an OWL data item diOWL_ψ gets committed as deleted by a transaction T and there exist other active transactions that started before T started. These transactions must still be able to read diOWL_ψ . In other words, a snapshot of a deleted data item diOWL_ψ can be discarded as soon as there are no more active transactions in the system that have a start timestamp smaller than the delete-commit timestamp of diOWL_ψ . Analogously, when a transaction T commits successfully its change set δ(T) needs to be kept if there are other active transactions T1. . . Tn in the system because δ(T)is required for conflict analysis against the change sets of T1. . . Tn to determine whether they are permitted to commit.

Testing for overlapping change sets can also be done more promptly (as opposed to doing it at the end). An algorithm for the read/write model called first updater wins that acts this way has been described in [FOO04]. Transferring this algorithm to our model is straightforward: The first active transaction T1 to add/delete a data item diOWL_ψ is granted to execute the operation. If T1goes on to commit, any other active transaction that has updated diOWL_ψ immediately aborts. An active transaction T2 with tTs2 < tTc1 that attempts to update diOWL_ψ after T1has committed aborts upon that attempt.