Optimistic Offline Lock

freeMoney

I get the account object for an account number. It has balance of X.

You get the account object for an account number. It has balance of X.

I change the account object by withdrawing 100 units from it. I reduce balance to X - 100.

You change the account object by withdrawing 100 units from it. I reduce balance to X - 100.

I update the account by setting the balance to X - 100.

I commit.

You update the account by setting the balance to X - 100.

You commit.

In affect 200 units are withdrawn but the balance has been reduced only by 100.

Resolution

update Accounts set Balance = Balance - 100 where Id = 1 While this would solve the problem and it might be sufficient but this would couple the solution to SQL and it would extremely hard to implement in a lot of cases where multiple records in different tables get updated.
I/You >= TRANSACTION_REPEATABLE_READ ref: pessimisticLock. Pessimistic locking reduces concurrency.

updateLock

I get the account object for an account number. It has balance of X.

I change the account object by withdrawing 100 units from it. I reduce balance to X - 100.

You change the account object by withdrawing 100 units from it. I reduce balance to X - 100.

I update the account by setting the balance to X - 100.

I commit.

You try to update the account by setting the balance to X - 100.

Your update doesn't update anything as it used version number in the where clause, which has changed.