A transaction is atomic if it takes place entirely or doesn't happen at all. In no situation is the database left in a half-modified inconsistent state. The application code can issue read and write operations for a transaction within a session and either commit (make all the changes applicable and visible) or abort (none of the changes are made). Even if the applicable instance or the database instance that was performing the read/write crashes, the transaction stalls and is recovered later on, but never is the atomic constraint violated.

Let's see an example of atomicity. Consider the following simplistic pseudocode, which transfers $100 from account abc to xyz:

amountToTransfer:= 100 
beginTransaction() 
srcValue:= getAccountBalance('abc') 
srcValue:= srcValue - amountToTransfer 
dstValue:= getAccountBalance('xyz') 
dstValue:= dstValue + amountToTransfer 
commitTransaction() 

If the balances in the abc and xyz accounts were $200 and $300, respectively, then after the transaction commits, the state will be $100 and $400, respectively. If there is a crash or the application encounters an error, the transaction will roll back and the balances will stay at the original amounts—$200 and $300, respectively.