Atomic actions [6] involve three properties: (i) serializability, that ensures that the execution of concurrent atomic actions is equivalent to at least one serial execution; (ii) atomicity, that is, either all its effects become visible, or none do; and (iii) permanence of effect.
The last property requires objects involved in an atomic action to be kept in stable storage, so that, even if one of the hosts running a distributed atomic action fails, its effects are permanent.
The atomicity property requires a global coordination of all objects involved in an atomic action. If the atomic action is committed, all objects involved must have its states made persistent; if it aborts, all objects must be reverted to the states previous to the beginning of the atomic action.
The serializability property requires some kind of concurrency control on operations. There are optimistic and pessimistic policies. Pessimistic algorithms rely on locking for ensuring serializable executions; optimistic ones let separate atomic actions operate on separate copies of objects, and check for serializability at commit time.
Atomic actions may be totally controlled at the base level, for example, by providing a class AtomicAction that takes an instance of the Java standard class Runnable as its constructor argument. The method run of this argument is then executed inside the atomic action. If it terminates successfully, the transaction is committed; if it throws an exception, the atomic action may abort.
Concurrency control may take place transparently, at the meta level, using whatever selected policy. However, if it is a pessimistic one, it should be possible to pre-declare locks, for example, from both the base and the meta level.
Instead of explicitly creating and managing atomic actions in the base level, certain objects may be configured as atomic ones [38], so that every operation on that object is performed inside an independent atomic action. It may be useful for meta-level control of atomic actions to be able to specify that a particular operation should be performed inside a given atomic action, as a nested atomic action or sharing data with other threads running the same transaction.