Tamino XML Server Version 9.7
 —  Transactions Guide  —

Examples and Scenarios

This document covers the following topics:


Scenario 1: Read-only Scenario without Consistency Requirements

In this scenario documents are read from Tamino with the lowest possible consistency requirements. Documents may be read whose content may contain uncommitted changes of other concurrent transactions. This may lead to dirty reads and non-repeatable reads as described above. For an explanation of dirty reads and non-repeatable reads refer to section Concurrency Phenomena in DBMS of this document.

Start of instruction setCursor-free Approach

This scenario is not adequate in the following situations:

Important:
This is the scenario with the lowest degree of consistency of all the scenarios discussed here.

Top of page

Scenario 2: Read-only Scenario with Consistency Requirements

This scenario uses the isolation level "committedCommand" which protects against dirty reads, but not against non-repeatable reads.

The characteristics of this scenario are:

Tip:
This scenario is recommended for reading access to data with medium consistency requirements that does not change very frequently. The risk of non-repeatable read must not be high if this scenario shall be used.

This scenario is not recommended in the following situations:

Start of instruction setCursor-free Approach

Non-repeatable Read Operation

A non-repeatable read operation may happen in the following manner:

The following assumptions are made:

Transaction 1 is the transaction considered in this scenario using the isolation level "committedCommand". Transaction 2 can run on an arbitrary isolation level and use any possible locking mode.

  1. Transaction 1 reads document x

  2. Transaction 2 writes document x

  3. Transaction 2 performs a commit operation.

  4. Transaction 1 reads document x again.

Then transaction 1 performs a non-repeatable read operation.

The second read operation will be performed successfully, but the delivered result will be different from the result obtained in the first step. This is due to the fact that there was a commit operation performed between the two different read attempts, and the chosen isolation level is "committedCommand" which is equivalent to showing all committed results to other concurrent transactions. The locks set by transaction 1 are relinquished after the first read command completed.

Top of page

Scenario 3: Single Insert/Blind Update Scenario

In this scenario either new documents are inserted or existing documents are updated regardless of the contents of the database. This means that all database access is done exclusively with the _process and no read access or updates via XQuery occur. Complete documents are replaced in the database without previously checking whether the document is already present or what its content is. This scenario represents the maximum of performance for writing access, but it is of course limited in its applicability.

Execute the _process commands in session-less context. Do not specify any isolation level or lock mode explicitly.

It is recommended to apply this scenario if you have to store large amounts of data independently of conditions.

This scenario cannot be applied if any contents of the database must be read prior to writing to the database.

For instance, a Java application which only reads already committed data in a session-less context with basic consistency requirements could look like this:

Top of page

Scenario 4: Read-for-Update Scenario

In this scenario a document is first read and then changed afterwards. At the time the document is read it is clear (or at least likely) that an update of the document will follow. In order to prevent deadlock scenarios, the lock required for the update is already set at read time.

The occurrence of deadlock scenarios of the following type can be avoided if the lock mode is set to "protected" before reading the document:

T1   T2  
Read doc1 S on doc1    
    Read doc1 S on doc1
Update doc1 Wait for X on doc1    
    Update doc1 Wait for X on doc1
    Deadlock  

The following situation leads to the deadlock as both transactions wait for an X-lock being granted which will never occur. However, if the an X-lock is set already on reading document 1 (this is enforced by setting the lock mode to "protected" before reading the document) the following occurs:

T1   T2  
Read doc1 X on doc1    
    Read doc1 S on doc1 (will not be granted)
Update doc1 As X-lock is already on doc1    
Commit Relinquish lock on doc1    

Thus the deadlock is resolved as transaction 1 can continue without waiting.

This scenario only makes sense if:

If the conditions above are not met, this may lead to a large number of superfluous X locks. In that case it might be better to avoid possible deadlocks in another way.

Top of page

Scenario 5: Stable Cursor Scenario

In this scenario the same document is read more than once in the same cursor. The content of the document is guaranteed to be identical.

In order to accomplish this, the isolation level must be set to "stableCursor".

Start of instruction setStable Cursor Scenario - Cursor-based Approach

Top of page

Scenario 6: Deadlock Prevention Scenario

Lock acquisition in a fixed document order can also be used as a means in order to prevent the occurrence of deadlocks.

Top of page