Contents   Index

Isolation

Running transactions isolated from each other is to say that the execution of several transactions concurrently produces the same database state as some serial execution of the same transactions; the execution is serializable [6].

If transactions were not isolated then transactions that would maintain operation level consistency in a single-user, single-process system (i.e., in a system where transactions would be forced to run one after the other, serialized) could not be guaranteed to maintain operation level consistency in a multi-user, multi-process system. For instance, the two transactions in Figure 4.1 (p. ) would maintain operation level consistency, if they were isolated, but in the figure they are not, so they do not. I personally think that this is the reason why isolation is considered to be of great importance for transactions in (distributed) operating systems.

Figure 4.1: Non-isolated database transactions

The problem could be solved (or more precisely, laid in the hands of the programmers) with the use of locks (see the note below Figure 4.1, p. ). Few distributed operating systems have explicit locking, so they must serialize their transactions. Fortunately, I plan to have locking in my file system (because pessimism requires locking, see Section 3.3.1). I will put the same additional requirement on transactions as ORACLE does, i.e., that additional locking is required in order to guarantee system level consistency. This decision is based on the fact that it is (must be) hard to serialize transactions in a system with mobile computers when these might execute their transactions locally, long before they get in contact with any servers (while disconnected, for example).

  Contents   Index