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:
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.
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.
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.
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.
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:
Performing queries on data:
In X-Machine Programming: Use
the _xql
command for queries based on the query language
Tamino X-Query. Use the
_xquery
command for queries based on the query language
Tamino XQuery 4.
Processing data and storing it in the database:
In X-Machine
Programming: Use the
_process
command to store (insert or update) data. You can also use the XQuery
update insert command to insert data.
Updating data using XQuery
In X-Machine
Programming: Use the XQuery update
replace command to update data.
Deleting data:
In X-Machine
Programming: Use the
_delete
command to delete data. You can also use the XQuery update
delete command to delete data.
Creating new schema definitions:
In X-Machine Programming: Use
the _define
command to create new schema definitions.
Deleting schema definitions:
In X-Machine Programming: Use
the _undefine
command to delete schema definitions.
Tamino offers 3 transaction modes:
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.
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.
local transaction
mode
The local transaction mode is intended for executing local
transactions with explicitly committed transactions in a session context.
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.
global transaction
mode
The global transaction mode is intended for executing global
transactions with explicitly committed transactions in a session context. Using
the global transaction mode enables Tamino to
participate in distributed transactions. The global transaction mode is not
available in some APIs.
In order to support global transactions based on a two-phase-commit (2PC) protocol, Tamino offers a global transaction mode.
Tamino does not communicate directly with the 2PC coordinator. Instead it establishes an indirect communication channel via the Software AG product Universal Transaction Platform (UTX), which is installed automatically during the Tamino installation.
Configuration of UTX is possible by the System Management Hub (Tamino Manager). For more information on aspects of administration and configuration of Tamino's 2PC support, see the separate UTX product documentation and also the readme.txt file of Tamino for possibly relevant "last minute" information.
For .NET or COM+ client applications running on a Windows platform, support for 2PC is based on the Microsoft distributed environment, including the Microsoft Distributed Transaction Coordinator (DTC). The Tamino server to which the client application connects can be located on the same Windows machine or on a separate Windows or UNIX machine.
For Java client applications running on a Windows or UNIX platform, support for 2PC is available via an application server (for example, BEA WebLogic). The Tamino server to which the client application connects can be located on the same machine or on a separate Windows or UNIX machine.
On Windows systems using Microsoft DTC, 2PC is supported for COM+ and .NET client applications.
UTX integrates Tamino into Microsoft's transactional architecture defined by the main components
MTS,
COM+,
and Microsoft Distributed Transaction Coordinator (DTC).
UTX manages the communication based on a 2PC protocol with DTC which acts as the coordinator.
The following picture illustrates the components participating in Tamino 2PC usage scenarios and their interactions:
The Tamino client application
The Tamino client APIs
The Tamino XML Server
UTX
The coordinator (DTC)
The picture illustrates the single actions which occur when Tamino participates in a distributed transaction under control of DTC:
Tamino registers with UTX at server start-up or when the first global transaction arrives.
DTC as the coordinator creates a new transaction.
The Tamino client application issues a connect call to Tamino API.
Tamino API asks DTC for a unique identifier for the global transaction (the GTXid).
Tamino API uses the received unique identifier for connecting with Tamino.
Tamino enlists using GTXid via UTX.
UTX creates a relationship with DTC using the GTXid to enlist in the transaction.
UTX is then controlled by DTC. During the commit (step A in the diagram), DTC coordinates the transaction using 2PC (step B) and UTX plays the role of a subordinate transaction manager delegating the 2PC to Tamino (step C).
In Java environments on Windows and UNIX, Tamino provides 2PC via an application server (for example, BEA WebLogic or IBM WebSphere). The message passing mechanisms follow the XA+ specification for distributed transaction processing. The XA+ specification was originally published by the X/Open Company, which is now part of The Open Group (http://www.opengroup.org/).
UTX manages the 2PC communication between Tamino and the application server.
The following picture illustrates the components participating in Tamino 2PC usage scenarios and their interactions:
The Tamino client application
The Tamino API for Java
The Tamino XML Server
UTX as the communication resource manager (CRM)
The UTX proxy
The Java application server as the transaction manager
The picture illustrates the single actions which occur when Tamino participates in a distributed transaction under control of a Java application server:
Tamino registers with UTX at server start-up or when the first global transaction arrives.
The Java application server as the coordinator creates a new transaction.
The client application issues a connect call to the Tamino API for Java, via the XAResource/XADataSource.
The application server assigns a unique XA global transaction identifier (XAXid) to the new transaction.
The XAResource passes the XAXid to the CRM Java proxy. This informs UTX that a new transaction is starting, and UTX assigns a new unique global transaction identifier (UTXXid) for the transaction
The CRM Java proxy informs the UTX transaction manager that a new transaction is starting.
The Tamino API uses the received UTXXid identifier for connecting with the Tamino server.
The UTX proxy connected with Tamino enlists Tamino with the unique global transaction identifier.
UTX is then controlled by the application server. When the Tamino client application issues a commit (shown as step A in the diagram), the application server coordinates the transaction using a two-phase commit protocol (step B). The XAResource component forwards the request to the UTX proxy (step C) which passes the request to UTX (step D). UTX plays the role of a subordinate transaction manager delegating the two-phase commit requests to Tamino (step E).
