How ACIDic are Transactions really!

I got a little bit distracted while I was hearing about the ‘No SQL Databases’  , one of the key characteristics is they do not support Full ACID transactions,  This brings back  some of the memories. Not all of them pleasant, this is/was one of the sure shot menus to be served by the interviewers, be it job interviews or college viva.  Honestly, now I think the entire ‘ACID’ thing was little overdone. I have no disillusion that it is one of the widely written topics , a google search below brings 1.5 billon search pages, but I thought of making a point, may be at the cost of being repetitive.

I talk very briefly , highlighting key concepts.

ACID (Atomicity, Consistency, Isolation, Durability)

Atomicity:  Either all or none. Reverts to earlier state in case of a failure (system, hardware, software) . Handled by Recivery-management component

Consistency:  When the transaction is complete it is in a consistent state.  Responsibility of an Application Programmer.

Durability: Once a transaction is completed, the effects are permanent.  No failure can change the same. This is responsibility of recovery-management component

Isolation:  Concept of Serializability, responsibility of concurrency control

Read it again please carefully, is not concurrency and recovery all that we are talking.  Keeping consistency is like having commonsense, which is uncommonJ. 

I think we should talk about CR Properties rather than ACID.