An atomic action is an operation that at some level of abstraction appears to be atomic in the following sense: Either the action is executed completely (and successfully), or it has not happened at all. In particular, if it is not successful, it has not left any side effects.
Except for simple instructions at the processor level, no operation is really atomic in the sense that it performs only one state transition.
Most operations are implemented by a sequence of more primitive operations (i.e. programs), which in turn are implemented by sequences of even more primitive operations, etc.
In order for a higher-level operation to appear atomic, a number of precautions have to be taken: The lower-level operations must not make any “visible” changes before it is clear
that the top-level operation will succeed. For any temporary changes the lower-level operations make, it must be made
sure that they do not become visible, and that they can be revoked automatically should anything go wrong.
Atomicity: A state transition is said to be atomic if it appears to jump from the initial state to the result state without any observable intermediate states—or if it appears as though it had never left the initial state. It holds whether the transaction, the entire application, the operating system, or other components function normally, function abnormally, or crash. For a transaction to be atomic, it must behave atomically to any outside ‘‘observer”.
Consistency: A transaction produces consistent results only; otherwise it aborts. A result is consistent if the new state of the database fulfills all the consistency constraints of the application; that is, if the program has functioned according to specification.
Isolation: Isolation means that a program running under transaction protection must behave exactly as it would in single-user mode. That does not mean transactions cannot share data objects. The definition of isolation is based on observable behavior from the outside, rather than on what is going on inside.
Durability: Durability requires that results of transactions having completed successfully must not be forgotten by the system; from its perspective, they have become a part of reality. Put the other way around, this means that once the system has acknowledged the execution of a transaction, it must be able to reestablish its results after any type of subsequent failure, whether caused by the user, the environment, or the hardware components.
Unprotected actions: These actions lack all of the ACID properties except for consistency. Unprotected actions are not atomic, and their effects cannot be depended upon. Almost anything can fail.
Protected actions: These are actions that do not externalize their results before they are completely done. Their updates are commitment controlled, they can roll back if anything goes wrong, and once they have reached their normal end, there will be no unilateral rollback. Protected actions have the ACID properties.
Real actions: They affect the real, physical world in a way that is hard or impossible to reverse. Drilling a hole is one example; firing a missile is another. Real actions can be consistent and isolated; once executed, they are definitely durable. But in the majority of cases, they are irreversible, which means it is much more difficult to make them appear atomic, because the option of going back in case the proper result cannot be achieved does not exist. In some cases, pretending atomicity for a real action is not possible at all.
Problem: There is no way to get to Ripa from Pisa the same day, except in a rental car. But you do not want to drive at night.
Here is a simple travel application. Let us assume we want to go from San Francisco, CA, to Ripa in Italy. The reservation procedure could start like this:
One solution might be to have you go from Milan to Florence rather than Pisa, and then go by train from there. Or the situation might require your going from Frankfurt to Genoa, or perhaps somewhere else. The point is, given a flat transaction model, the travel agent has only two choices:
Issue ROLLBACK. This gives up much more of the previous work than is necessary; in particular, there is no need to give back the reservation on the flight to Frankfurt.
Explicitly cancel all the reservations that are no longer useful. This is tedious at best. Furthermore, explicit cancellation might not be so easy, because some of the very cheap special fares come with a high cancellation fee.
Assume there are 1.000.000 checking accounts. Assume the transaction has done the interest processing of
983.446 accounts. Assume the system crashes at that point. Thanks to atomicity (the A of ACID), all the updates that have
been done so far (983.446 of them) will be rolled back - even though none of those updates was incorrect in any way.
After the rollback, the database will be in the state before the transaction started. So if you are the database administrator, you have lost hours worth of work - and probably have made some customers very angry.
Bjork and Davies in the early 70s established the notion of spheres of control (SOC); the following definitions are largely quoted from their seminal paper:
Process control: Process control ensures that the information required by an atomic process is not modified by others, and it constrains the dependencies that another process may place on the updates made by this process.
Process atomicity: Process atomicity is the amount of processing one wishes to consider as having identity. It is the control over processing that permits an operator to be atomic at one level of control, while the implementation of that operator may consist of many parallel and/or serial atomic operators at the next lower level of control.
Process commitment: While a function is in process, changes of state are being made only by that function or they are expressly known to that function. This allows the establishment of a single point to which one can return for rerun purposes independently of the error detected or the number of functions since that point. Preventing process commitment by holding (controlling) the use of its results permits the system to perform a unilateral backout (process undo) over much larger units of process. Unilateral here means without having to request permission from each participant in a process. In summary, process commitment control is the containment of the effects of a process, even beyond the end of the process.
Structural dependencies: These reflect the hierarchical organization of the system into abstract data types of increasing complexity. The atomic action surrounded by SOC B4 is structurally dependent on A2, because the implementation of A2 uses B3 (as well as B4 and 5). The consequence of this - forgetting about sphere S for the moment—is that none of the results produced by B3 can finally be committed (even though they appear perfectly good from B3’s perspective) until A2 decides to commit. The reason is simple: A2 appears as an atomic action to the outside. So, as long as it has not decided which way to go (all or nothing), everything it has done—either by itself or by invoking lower-level atomic actions—must remain contained inside A2’s sphere of control. In that sense, the commit of B3 depends on the commit of A2.
Dynamic dependencies: As explained previously, this type of dependency arises from the use of shared data. Let us briefly recapitulate the idea illustrated in Example 1. Up to a certain point, A1 and A2 are disjoint atomic actions. Some action within A1 has produced data object D, but A1 is still active. If someone inside A2 uses D, then it is quite obvious that any results based on that become wrong at the moment A1 decides to roll back, because that makes D return to its previous value. As a consequence, A2 has become dependent upon A1 in the sense that A2 can commit only if A1 does. Structural dependencies reflect the invocation hierarchy of the system, whereas dynamic dependencies can envelop any number of otherwise unrelated atomic actions.
Active part: As can be seen from the state-transition diagram, there are three events causing an atomic action to change its state: the BEGIN WORK, the ROLLBACK WORK, and the COMMIT WORK. Transaction models can define conditions that trigger these events. Consider the example in the SoC scenario again: the event ROLLBACK WORK for atomic action B3 can be triggered by the program running inside B3 (this is true for all atomic actions); but, because of the structural dependency, there is an additional condition saying that the abort of A2 triggers the rollback of B3.
Passive part: Atomic actions that depend on other transactions might not be able to make certain state transitions all by themselves. For example, the signal COMMIT WORK for B3 is not sufficient to actually commit B3; that can only happen if A2 is ready to commit, too, since A2 is the higher-level sphere of control.
In that case it would help if we could do a partial rollback rather than aborting the entire transaction.
So if we could say: Rollback to the state S2, we would be back to Milan, so to speak.A rollback to the state S1 would get us back to Frankfurt, while still being in the same transaction.
S3: book flight from Milan to Pisa, same dayS2: book flight from Frankfurt to Milan, same day
Savepoints can be used to structure a transaction into a sequence of partial executions that can be rolled back individually.
Because none of the actions a transaction has executed become “visible” before the end of the transaction, they can be revoked at any time.
Since a transaction must be prepared to roll back completely, a partial rollback does not add anything new, technically.
When a transaction rolls back to an internal savepoint, the actions that are undone appear like they had never happened - even to the transaction itself.
When an external error occurs, the entire transaction gets rolled back - independent of any savepoints.
All the steps between two Save Work commandsare encompassed by anatomic action. These atomicactions are threaded together by commit- and abort-dependencies.If one of them gets aborted,all subsequent atomic actionsare aborted, too.If one of them commits, itcauses all the previous onesto commit, too.
a) The first transaction in the chain has been started; start of the second one will be triggered by commit of the first one.
A B C
A C
A B C
A C
system C1
trigger
A B C
A CC2
trigger
A B C
A CC3
b) The first transaction in the chain has committed; the second one got started as part of commit of C1. Now the second one is structurally dependent on "system".
Workflow structure: Chained transactions allow a substructure to be imposed on a long-running application program, just as savepoints do.
Commit versus savepoint: Since the chaining step irrevocably completes a transaction, rollback is limited to the currently active transaction.
Lock handling: COMMIT allows the application to free locks that it does not later need.
Work lost: Savepoints allow for a more flexible state restoration than do flat transactions only as long as the system functions normally.
Restart handling: The chained transaction scheme, on the other hand, reestablishes the state of the most recent commit; that is, less work is lost in that situation.
A nested transaction is a tree of transactions, the sub-trees of which are either nested or flat transactions.
Transactions at the leaf level are flat transactions. The distance from the root to the leaves can be different for different parts of the tree.
The transaction at the root of the tree is called top-level transaction, the others are called sub-transactions. A transaction's predecessor in the tree is called parent; a sub-transaction at the next lower level is also called a child.
A sub-transaction can either commit or rollback; its commit will not take effect, though, unless the parent transaction commits.
The rollback of a transaction anywhere in the tree causes all its sub-transaction to roll back. This combined with the previous point is the reason why sub-transactions have only ACI, but not D.
Commit rule: The commit of a sub-transaction makes its results accessible to the parent transaction only. The sub-transaction will finally commit (i.e. release its results to the outside world) if and only if it has committed itself locally and all its ancestors up to the root have finally committed.
Rollback rule: If a (sub-) transaction at any level of nesting is rolled back, all its sub-transactions are also rolled back, independent of their local commit status. This is applied recursively down the nesting hierarchy.
Visibility rule: All changes done by a sub-transaction become visible to the parent transaction upon the sub-transaction’s commit. All objects held by a parent transaction can be made accessible to its sub-transactions. Changes made by a sub-transaction are not visible to its siblings.
Assuming sequential excution in all modules and transaction protection per module, we get the following nested transaction (let Tx be the transaction protecting the execution of function_x):
Multi-level transactions can be used if the following structural requirements are fulfilled:
Abstraction hierarchy: The entire system consists of a strict hierarchy of objects with their associated operations.Layered abstraction: The objects of layer n are completely implemented by using operations of layer n-1.Discipline: There are no shortcuts that allow layer n to access objects on a layer other than n-1.
With all the transaction models introduced so far there is one problem that has been mentioned before, namely how to proceed when the unit of consistent state transition requires updating all of the bank’s one million account records at the same time.
By making the whole update operation a flat transaction, the “exactly once” semantics are obtained, but at an unacceptably high price in the case of a restart will be charged by the system. Neither making a nested transaction nor taking savepoints will help, because in either case the acid property is still maintained for the entire transaction.
Such additional structuring may help to organize normal processing, but it does not contain the amount of work lost in case of a crash.
Transaction: Cursor c introduced earlier falls into this category. Since sql cursors cannot be passed across transaction boundaries, a cursor position is a typical example of transaction context.
Program: If a program executes a series of transactions, then program context contains the information about which transaction was committed last.
Terminal: Terminal context may contain a list of users who are allowed to use this terminal, a list of functions that can be invoked from that terminal, the last window that was displayed on that terminal, and so on.
User: User context may contain the next password the user must produce in order to be admitted, or the last order number the user has worked on, and so forth.
Finally: Let Us Consider the Banking Application Again
When you organize the update of the 1,000,000 accounts into, say, 1,000 transactions, each of which does 1,000 updates, then the problem is that after a crash you do not know which accounts you already touched.
One “solution” would be to add an attribute to the Accounts - relation that contains the date of the recent interest computation. After a crash one could find the account with the lowest account number that has a date older than the current day in this attribute. That is the point from which to resume the interest computation.
The problem with this approach is twofold: First, you introduce an attribute into the Accounts relation which otherwise you
would not keep at all. So it has nothing to do with the application, but with problems of system administration.
Second, finding the point for resuming the computation after a crash is fairly expensive (finding the minimum of some attribute value requires the system to touch all tuples).
It would be better to have some place in the database that always points to the point beyond which interest has to be computed.
First, we have the Accounts relation: Second, we have a Restart relation:
Restart
A tuple in the restart relation specifies, at which point long-running computationstouching all tuples must be resumed incase the computation gets interrupted bya crash. Normally, the “last OK account”is 0, which means no long runningcomputation is active. Otherwise, it contains the highest account number processed by the last successful transaction.
