AtomicOperation is a BufferedStore that transports to the Engine (or a Transaction)
AtomicOperation uses just in time locking so it never block other operations before it goes to commit
- When committing, AtomicOperation grabs locks to create a fence around the resources on which it will operate. It does not release these locks until it is done committing
AtomicOperation listens for version changes to the resources that it intends to lock. If it is notified about a version change it fails immediately.

Note

TODO: may have to move durability up from Transaction to AtomicOperation

What happens if a crash occurs while a Transaction is committing? If we don't take a backup of the operation before committing, then we can end up in a state where the AtomicOperation is partially committed once the server restarts.
- This would seem to violate the "all or nothing" promise of atomic operations.
  - Or maybe it doesn't violate "all or nothing", but does violate consistency and durability. But AtomicOperations don't guarantee those.
    - If you want C and D then use a Transaction...right?
Tacking backups will make atomic operations slower. Atomic operations are meant to be fairly limited in scope (e.g. very few compounded operations), so is it necessary to worry about crashes leading to partially committed operations?

Atomic Functions in Concourse Server

...

Versions Compared