User Functions

Older Stories

Welcome to Saturday, 29 April 2017, 09:32 @ CEST

ACID - Atomic, Consistent, Isolated, Durable

Design Patterns
  • Wednesday, 28 August 2013, 10:16 @ CEST
  • Contributed by:
  • Views:
In reference to

Rule: any program action should be atomic, consistent, isolated and durable.

Well, what does this all mean? When your program is the single rununit in a single user system, there is probably no problem. But things get complicated when multiple users launch all kinds of run units and are expecting that the whole system is able to synchronize all actions.
And ACID requirements drill down to the persistence layer: storage, the file system, a database.

Being atomic means that your program design can guarantee that nothing can interfere between the start and end. By decomposition of your design in chunks, the requirement can be implemented for each individual chunk.

Being consistent means that your program will not (but it would be better to say "cannot") leave the system in a invalid state. At no times. Events to consider are crashes, abends, power loss.

Isolation comes down to a type of processing that can assume that your run unit is the only one running. So, running a system with hundreds of users and/or multiple run units will have the very same effect on the system as if all these transactions are executed serially. An important effect is that the system must be able to be replayed serially. Always.

Durability is necessary to reach a durable state. Which means that any action of the program that results in a storage of results, these results must be durable present. So, no excuses like caching, blocking, buffering, asynchronous transactions and on. Any commit must be durable as if a backup is extracted.

If you system exhibits these ACID properties, you probably have concurrency in control. You may read more under File Lock, Record Lock, SemaPhore.

- copy and delete is not ACID. Use move (mv) for this, which is similar as rename.
- update and log a journal; both should be ACID and synced. So sequence the actions like update, than log, than commit.
- system time; make sure that rewinding the system time does not interfere. This may happen in environments that use load balancing or are distributed, by a system fallback, etc.

The following comments are owned by whomever posted them. This site is not responsible for what they say.