Tamino XML Server Version 9.7
 —  Transactions Guide  —

Transaction Modes

This section introduces and explains the most important terms of transactionality in the context of Tamino, compares the general transaction modes and gives general information about the locking concept which implements Tamino's transaction support. In detail, the following topics are discussed here:


Basic Definitions

Before the transaction modes of Tamino will be explained in detail, the main terms used in the description of the granularity of transaction execution need to be defined exactly.

Session

As with most of the other databases, local transactions within Tamino always take place within the context of a session. A session manages the connection from an application to the Tamino database. You can consider sessions as a channel between your application and the database that is opened at the beginning of the session and closed at the end of the session. In Tamino, a session is opened with a _connect command and closed with a _disconnect command. Within the context of the session, a series of single transactions can be performed until the termination of the session.

Note:
For distributed transactions, there is a many-to-many relationship between sessions and transactions: Several sessions can belong to one single distributed transaction.

Transaction

As mentioned above in the description of the ACID criteria, a transaction represents the unit of work (as defined by the user) that must be performed in its entirety to ensure logical consistency of the information contained within the database. Within a session, there is at most one transaction at a time.

In Tamino, a local transaction always begins with the first command acquiring a lock following a _connect, _commit, or _rollback command (in the 2 last cases the transaction is started implicitly) and ends when a _commit,_rollback or _disconnect command is issued for the transaction.

Note:
Every read, insert, update, delete, define or undefine operation opens a transaction because each of these commands requests locks.

Request

In general, a request can be either a single command or a group of related commands.

Currently all Tamino APIs only support requests consisting of one single command, the only way to bundle more than one command in a single request is to access Tamino directly via its HTTP protocol. The terms "request" and "command" can therefore be used synonymously in most cases. In the examples on the next pages the distinction between "request" and "command" is maintained only for reasons of completeness.

Command

A command is an elementary operation within the database. All Tamino commands are relevant in the context of transactionality. Also see the section Transaction-Related Commands of the X-Machine Programming manual.

An application can communicate with Tamino either directly on the protocol level via HTTP or through a programming language specific API.

Note:
This document explains the general transactional concepts of Tamino independent of the chosen method of communication. Thus details of particular APIs are not discussed here (refer to the documentation of the particular API for those) and terms for the various operations will not always match precisely the term used in your API. Sometimes command names from X-Machine Programming or the APIs will be used as an example in this document. For all other APIs there is always a similar command available.

Commands are available for the following elementary operations:

Top of page

Summary of Transaction Modes

Tamino offers 2 transaction modes:

  1. session-less mode (auto-commit)
    The session-less (or auto-commit) transaction mode is intended for executing local transactions with implicitly committed transactions in a session-less context.

    graphics/SessionlessContext.png

    In a session-less context (also called an "anonymous session"), requests run without a user-defined session. Then every command in a request is executed in a separate (single-command) transaction and will be implicitly committed if the response code indicates successful execution or will be implicitly aborted (rolled back) otherwise.

  2. local transaction mode
    The local transaction mode is intended for executing local transactions with explicitly committed transactions in a session context.

    graphics/SessionContext.png

    A session is established by a connect command. It can consist of one or more transactions containing one or more single commands that are performed during this session.

    A transaction is implicitly started by the first command after a connect command or after the preceding transaction has completed.

    A transaction is either explicitly closed by the application with a rollback or a commit command, or implicitly committed when the corresponding session is closed.

    Note:
    Not every command starts a new transaction, only those commands that trigger a lock.

Top of page