Concurrent updates get interesting when they are based on reads that happened earlier. Then applying updates atomically doesn't buy you anything - you still nee

Concurrent updates get interesting when they are based on reads that happened earlier. Then applying updates atomically doesn't buy you anything - you still need to either lock the object so that noone modifies its state between the read and the update (pessimistic locking), or be prepared to abort an update if a concurrent change to the object is detected (optimistic locking), or to append the update instead of overwriting previous state and eventually resolve / fix later, which is not always possible and may be just as hard as getting the locking right. Additionally, being too optimistic about shared resources management may lead to really bad user experience - like being kicked out at the gate because the flight is overbooked or like being fined for overdrawing your debit-card by offline transactions. You just need to pick your poison ;)