ACID compliance

Condensation is ACID compliant. The following discussion applies to the public and private data of an actor, as well as a system of actors communicating through messages.

Atomicity

To apply a transaction (data modification), a new tree is derived and uploaded onto the store. When ready, the hash of that new tree is added to the box, resulting in an atomic commit:

• Adding the hash applies the transaction in its entirety.
• If adding fails, the old state is retained in its entirety.

Since the data is forward-moving, removing obsolete hashes is merely cosmetic, and only affects the performance.

Note that the above atomicity directly depends on the atomicity of the store's add operation. This is usually easy to accomplish, even for raw storage:

• If all 32 bytes of the hash get correctly written to the storage system, the operation succeeds.
• If one or more bits are not written, or flipped, the resulting hash very likely does not point to an existing object, and is therefore invalid. The old state remains.

Consistency

Each transaction moves the data from one valid state to another valid state of the forward-moving data structure. Higher-level constraints have to be implemented by the application.

Isolation

Multiple independent transactions may run concurrently, and won't affect each other. When reading the data, all changes are be merged.

Durability

A committed transaction is durable on the applied store, and will remain committed throughout the lifetime of the store.

The lifetime of a store depends on the nature of the underlying storage system. On non-volatile storage, such as a hard disk or solid state drive, a store lives until the drive fails, or until the store is wiped. On volatile memory, such as RAM, a store lives until power is removed, or until the process managing the store exits.