Contents   Index

Properties of Transactions

In the world of (distributed) operating systems transactions normally have four properties: atomicity, consistency, isolation, and durability (ACID). As far as I know, the only transactions that have been designed for mobile computing do not uphold all of these properties, in fact they only guarantee isolation (see [30], [31]) which is "funny" since that is the only property of the four properties mentioned that is normally not provided with database transactions.^4.2

In the following three subsections each of the CID properties will be treated separately, constantly comparing them to properties of database transactions. The subsection on isolation will discuss the isolation-only transactions (IOTs) in more depth. The A for atomicity has already been treated, its the "all-or-nothing" property:

In my point of view it makes no sense to discuss transactions that are not atomic--why are they called transactions?

One can either agree with me on this matter or not. If one does not, then the rest of this chapter will be of no use.

Some applications may find it useful to nest transactions, even though by allowing this it is impossible to uphold all of the four ACID properties for both inner and outer transactions, see Section 4.1.4.

Warning: When the term transactions is used in connection with databases it is understood, that they are atomic, consistent, and durable (but not necessarily isolated), see, e.g., [5]. In the operating system world the terms transactions [4], [34] and atomic transactions [46], [47], [52] (implying that there can exist non-atomic transactions) are used interchangeably and it is normally understood (in both cases) that they have the ACID properties. Furthermore, I am not convinced that there is agreement on the use of the term consistency, which I will return to in Section 4.1.1.

Unless otherwise stated I will assume that transactions have the ACID properties (as these are defined below), and that database transactions are atomic, durable, and consistent.

Footnotes

... transactions.^4.2

In ORACLE, for example, you must use explicit locking in order to avoid conflicts, see Section 4.1.1.

  Contents   Index