Database ACID characteristic
Database operation provides ACID characteristics.
Atomicity: All operations either occur or fail and are treated as single instructions.
Consistency: Any rules set (cascades, indexes, triggers) are correctly executed.
Isolation: Concurrent behavior shall be the same as sequential behavior.
Durability: Changes are persisted and shall not be lost, even with a DMBS crash.
Caveat:
In the banking scenario, each access (GetBalance, SetNewBalanceToDB) follows ACID, but the database has no knowledge (or control) over the additional logic.
Databases provide notions additional mechanisms to enforce ACID with macro operations.
CWE-362 – Example - Banking
Locks
DB is locked.
No other operations take place.
Transactions
DB Operations are queued.
Queue is discarded or committed atomically
Versioning
At Commit();
DB version is acquired. Commit may FAIL if another change took place.
Improper Synchronization
Direct solution:
Protect changes with a mutex.
Developer assumes lock/unlock always work.
CWE-362 – Race Condition – Isolated Ops
X86_64: i++ with gcc
X86_64: i++ with clang
ARM: i++
Developer thinks: i++
is a single operation.
In reality... it depends, and varies with the architecture.
Still (generic behavior).
Value of “i" must be available (previous logic).
Value must be fetched from RAM to Cache.
Page must be addressed and then loaded.
MMUs and other systems are used.
Value must be fetched from cache to Register.
Register as to be increased.
Result must be stored in Cache.
Result shall be committed to RAM.
CWE-362 - Improper Synchronization
The following function attempts to acquire a lock to perform operations on a shared resource.
The code does not check the value returned by
pthread_mutex_lock()
for errors.If
pthread_mutex_lock()
cannot acquire the mutex for any reason, the function may introduce a race condition into the program and result in undefined behavior.
Last updated