Because you have updated your reply with more information I make a new reply instead. My old reply still stands about the what the article said and my use of op

Because you have updated your reply with more information I make a new reply instead. My old reply still stands about the what the article said and my use of optimistic locking. Databases do support locks, usually called pessimistic locking (opposite of optimistic locking). In a RDBMS that is usually a table lock or a row lock. Table locks are usually bad for performance and row locks better, however both are clumsy to work with, this is where the simplicity of optimistic locking comes in. Where pessimistic locking is part of the RDBMS itself, optimistic locking is something that you implement yourself on top of the RDBMS. Optimistic locks are lightweight (optimal case one read and one write) and easy to implement and understand. In the example in the article I would have argued for optimistic locking on all cases and it would have worked with multiple instances. Transactions and locks does not serve a similar purpose.