Need a new transaction method for engineering data?

Several application areas such as e.g. data warehousing, CAD, CASE, multimedia, and workflow management cannot always accept the constraints of classical transaction manage-ment. APOTRAM provides attrac-tive solutions whenever users need to share data; whether the issue is merely looking at data items that have not yet been finalised, or full-blown collabor-ation between two or more users.

When a user manipulates or interacts with a database, his or her actions will normally happen as part of a transaction. The point of using transactions in the first place, is to prevent things from going wrong. Many things could go wrong if transactions were not used. A user could, for example, insert, delete, or change something in the database, and have the effects of his or her work nullified by another user (the so-called lost update problem). Similarly, a user may retrieve a piece of data thinking that its value is reliable, while in reality that value is in the process of being changed by another user, and therefore may not be reliable at all (the so-called dirty read problem).

Any decent database manage-ment system (DBMS) will support transactions (typically by means of locking), and the behaviour of such transactions is captured by the acronym ACID, which stands for Atomic, Consistent, Isolated, and Durable. ACID transactions prevent almost any problem you can think of, save those caused by floods, fires, earthquakes, or other major disasters. Therefore, everyone agrees that ACID transactions are great for banking, airline reservations, and other classical applications of database technology.

However, there is also broad consensus that ACID trans-actions are unsuitable for a number of other application domains, the common denomin-ator of which is typically the need for long-lasting trans-actions, i.e. transactions whose duration is measured in hours, days, or months, rather than seconds or minutes.

First, ACID transactions employ a very strong notion of conflict, which causes one transaction to block another whenever at least one of them tries to perform a write operation and they both access the same data item, resulting in the second trans-action having to wait until the first one completes. Waiting for a few seconds may only be a minor problem, but waiting for hours or days is usually unacceptable.

Second, the I in ACID prescribes total isolation between trans-actions. Such isolation is known as serializability, since trans-actions behave as if they executed serially (i.e., as if they had the database all to themselves). This is just what you want in classical database applications, but is counter-productive for users who need to share information with each other or participate in some form of collaborative work. Therefore, something more general and flexible than the ACID transaction model is required.

This is where APOTRAM makes a contribution. Rather than insist-ing on unconditional isolation between transactions, APOTRAM allows the degree of isolation to be customised, and introduces the notion of conditional isolation (not to be confused with the SQL standard's concept of isolation level). The isolation property is generalised in two different ways; one way that enables readers and writers to share data, and another that enables writers to perform collaborative work on a set of data items.

The first of these generalisations can be implemented by means of standard locking techniques where locks have user-defined parameter values associated with them, and the second can be implemented by allowing locks to be applied recursively. The formal basis for all of this is provided by generalising the definition of serializability, or conflict serializability to be precise. The data sharing stuff is captured by conditional conflict serializability (CCSR), and the collaborative work stuff is captured by nested conflict serializability (NCSR). CCSR and NCSR can be used independ-ently of each other, or in combination.

The result is a much more general transaction model with ACCID rather than ACID properties. That is, transactions are still Atomic, Consistent, and Durable, but the (unconditional) Isolation demanded by the ACID model has been replaced by Conditional Isolation, hence the extra C in ACCID. Simply put, this means that users are now free to choose how much concurrency should be allowed. If they want the good, old ACID properties, APOTRAM will provide that by default. If the concurrency thus provided is inadequate, they can explore the new possibilities that ACCID transactions open up to them. Transactional behaviour can be tailored to meet the needs of individual applications (which is why this model is labelled "application-oriented"). Another important aspect of APOTRAM is that ACID and ACCID transactions can co-exist, without the former influencing the results of the latter (although long-lasting ACCID transactions can cause ACID transactions to wait for locks, thus degrading their performance). The model is based on a straightforward mathematical generalisation of classical transaction theory, and so has a sound formal found-ation. Still its greatest strengths are probably simplicity and generality. APOTRAM is simple to implement and use, yet powerful enough to meet the needs of a large class of applications.

It should be noted that EPM will be doing an implementation shortly and products will be planned to be available for testing later this year.

For further information contact:

Dr Ole Jörgen Anfindsen
Telenor R&D

www.telenor.com

www.apotram.com