Transactions

Transactions

We observed that a classical approach of a fully-fledged distributed database system does not fit the needs of the EDOS project. The various actors in EDOS require a certain degree of autonomy and the network consists of many transient nodes. A distributed database, however, brings along a high degree of control and requires tight collaboration between actors, which is not desired in the present environment.

Instead of providing a separate distributed database architecture for WP4, we decided rather to integrate well-proven (distributed) database services/techniques into the P2P architecture and to adopt an integrated architecture. We came to the conclusion that the proposed P2P architecture would benefit a lot if we integrate transaction support for the file/package upload and download so that we can guarantee a certain degree of control and consistency for the file upload and download, i.e. relaxed ACID properties. To start our discussion we provide a state of the art summary of the concept of transaction in database technology.

A transaction in database management systems is defined as a logical unit of database processing, i.e. it refers to one or more database access operations (i.e. insertion, deletion, modification or retrieval of data). One way of specifying transaction boundaries is by explicit begin transaction and end transaction statements. All operations between these two statements form the transaction. The database is in a stable and consistent state before the transaction starts, and its state is stable and consistent again when the transaction ends. If a transaction fails, it is aborted and a rollback is performed in order to rebuild the previous state of the database [27].

ACID

Transactions should have the following properties: Atomicity, Consistency, Isolation and Durability, also known as ACID properties.

• Atomicity: A transaction is an atomic unit of processing. It is either performed entirely or does not leave any effects at all.
• Consistency: A transaction is consistency preserving in that its full execution takes the database from one consistent state to another.
• Isolation: A transaction should appear as though it is being executed in isolation from other transactions. That is, the execution of a transaction should not interfere with any other transaction executing concurrently.
• Durability: The changes applied to the database by a committed transaction must persist in the database. These changes must not be lost whatever failure might occur.

However, there are some application areas (i.e. non-standard application areas such as workflow environments and CAD) where an ACID transaction is too strict. In a workflow environment for example, where several users work together, a transaction can take a very long time, e.g. if the interaction of different users is required and there are several waiting points within the process. Therefore, new concepts for non-standard transactions in different non-standard application areas have evolved, e.g. nested transactions or long transactions.

In the following, different non-standard transaction approaches are presented.

Long Transactions

Long transactions are transactions that take (much) longer time than normal transactions (from several minutes to several days, weeks or months). A long transaction takes too long to be allowed to hold locks that another transaction needs. Consequently, the ACID properties must partially be violated.

In [28] the saga approach is introduced: A saga is a collection of actions, that together form a long-duration transaction. Formally, a saga consists of a the following components [36]:

• A collection of actions
• A graph whose nodes are either actions or special abort or complete nodes, and whose arcs link pairs of nodes. No arcs leave these two special nodes, which are called terminal nodes
• An indication of the node at which the action starts, called start node.

Compensating Transactions. In a saga each action A has a compensating action, which is denote as A^-1. If we execute A and later execute A^-1, then the resulting database state is the same as if neither A nor A^-1 had executed [36]. By the property of compensating transaction the effect of the saga is negated and the database state is the same as before the initial transaction A.

Nested Transactions

In contrast to flat transactions, nested transactions can be seen as a tree of transactions. The transaction at the root of the tree is called top-level transaction, the others are called sub transactions. Transactions at the leaf level are flat transactions, all the other transactions are nested [29]. Their basic structured is illustrated in Figure 1. TA 1 is the top level transaction, TA 11 is a sub transaction and TA 12, TA 111 and TA 112 are (flat) leaf transactions .

Nested Transaction

Nested transactions can either be open or closed, which is defined by the lock keeping behavior of the top level transaction: In closed nested transactions all locks acquired by sub transactions are kept until the top level transaction ends. In contrast to a closed transaction, locks acquired by sub transactions of an open nested transaction are released at the end of the respective sub transaction. Consequently, open and closed nested transactions do not correspond to the ACID principle. For closed nested transactions, ACID properties are guaranteed for the top level transaction (TL-TA). For the sub transaction (sub-TA) consistency, atomicity and isolation can be guaranteed, whereas durability can not be guaranteed until the top level transaction is executed entirely and successfully. Otherwise, in case one of the sub transactions fails, all primarily committed sub transaction are rolled back. Their effect is consequently not durable until the top level transaction has committed successfully [29].

Closed nested transactions are extremely useful if modularization is an issue: they enable the decomposition of a complex operation into sub operations which are executed using sub transactions.

Distributed Transactions

Whereas the structure of a nested transaction is defined as a functional decomposition, the structure of a distributed transaction depends on the distribution of the data in the network.

A distributed transaction is typically a flat transaction that runs in a distributed environment. The transaction is executed at a number of different nodes (all distributed over the network) at which the transaction accesses the local database. The coordination of the transactions is more complicated then with a centralized approach since all the coordination mechanism must adapt to the distributed environment (e.g. distributed concurrency control etc.) [32].

Mobile Transactions

In contrast to traditional transactions mobile transactions are initiated by a mobile client. They have to deal with disconnection periods and cell handovers during the transaction execution.

Mobile transactions can be classified according to the capability of the client to connect to the server or other peers. Connected mode means that the client is not necessarily connected all the time, but a connection can be established, if required. With the disconnected mode the transaction is executed locally (on the mobile) on replicated data. Synchronization takes place as soon as the client connects next time [31].

Several different transaction models were proposed for both mobile transaction classes [34], including Clustering, HiCoMo, Prewrite, Semantics-based, Pro-Motion, Kangaroo Transaction and some more.

Transactions in P2P environments

In [35] a concept for grid transaction processing is presented. The authors concentrate on decentralized concurrency control for transactions in a grid environment in which no central control is required. Services (web services) are seen as transactions which are invoked by a node and are usually processed on (many) other nodes. These transactions consist of a number of service calls, where each service call can be processed on a different node.

Dependencies between transactions are managed by the transactions themselves. The protocol relies on a decentralized serialization graph, where each node and each transaction maintain a local serialization graph. The serialization graph of the peer reflects the dependencies of the transactions that invoked service calls on that peer whereas the serialization graph of the transaction includes the dependencies in which the transaction is involved.

In [30] the DSGT (Decentralized Serialization Graph) protocol is presented. DSGT ensures concurrency control and recovery for services (i.e. transactions) in P2P environments. This work could build a basis for the transaction support planned for the EDOS distribution architecture. However, it doesn't address the consistency issue, which is very important within the EDOS environment.

In [33] an approach for agent-based transaction in a decentralized P2P network is presented. The focus is on a new form of cooperative information system based on a P2P model. The model consists of a multi agent system with 4 components (wrapper, mediator, facilitator and planner) which are responsible for the management and control of transactions composed by data management operations (read, write, delete) and their outcomes. ACID properties are not addressed.