ACID compliance outdated, needs total revamp
Traditional databases are often touted ACID (atomicity, consistency, isolation, durability) compliant, which means that they handle transactions properly. Condensation obviously handles transactions properly as well, but due to differences in the data model, not all ACID properties apply in the same way as they do for databases.
ACID for roots
The purpose of a transaction is to bring a system from its current consistent state to another consistent state, without passing through any intermediate (potentially inconsistent) states. The state of a Condensation system is entirely represented by its roots, as this is the only mutable part of the system. Simply adding an (immutable) object without linking it through any roots does not change the state of the system.
Hence, strictly speaking, ACID only applies to roots, and root updates fulfill the 4 properties:
- Atomicity: Root updates are atomic. The hash is updated atomically, and concurrent reads see either the old hash or the new hash.
- Consistency: The server checks if the provided hash is a valid (although not necessarily existing) 256-bit hash, and refuses to store a hash of different length.
- Isolation: Root updates are applied sequentially.
- Durability: The update is permanent.
ACID at higher level
ACID compliance is usually desired at some higher level, and Condensation makes it easy to build applications that provide an ACID compliant interface. You can carry out an ACID compliant transaction as follows:
- Read the current hash, H, of the root.
- Read the object tree H, and prepare the new object tree, N. You may read other object trees, or data from other sources as well, of course. Check the consistency of the new object tree.
- Submit all new objects to the Condensation server, and wait for confirmation.
- Post a transition from H to N on the root. This will fail (abort) in case the state has been altered in the meantime, and succeed (commit) otherwise.
Atomicity is guaranteed by (4), consistency by (2), isolation by (1) + (4), and durability by (3) + (4).
In the context of traditional database systems, durability is usually guaranteed when the system crashes (e.g. due to power loss) but non-volatile storage survives. Durability is not guaranteed in case the data hard disk crashes. This concept of durability is weak, and of little value.
Absolute durability cannot be achieved theoretically. There is always a potential worst case in which everything fails. From a probabilistic point of view, durability can however be traded against cost and delay, and this is the concept used by Condensation.
Flushing every change to non-volatile memory may not be the optimal trade-off, but arbitrarily low failure probabilities can be achieved by replicating roots (and objects).