4 ms·

No, locks work. Lock is needed if you need to do some sort of complex computation before writing, like updating a JSON blob.

by tored 6y ago

lostcolony 6y ago
As both I and the parent said, "If you have multiple instances". In which case, locks (like those mentioned in the article) don't work. Because instance A reads 0, instance B reads 0, instance A writes 50, instance B writes 50. Totally serialized on each instance, totally unpredictable in when they hit the DB. Just like you have a lock serving as a synchronization point on an instance, in the case of multiple instances, you want to push the synchronization point down into a single instance at the data layer (which you often have when using a traditional RDBMS). But RDBMS' don't have locks, per se, for that synchronization; they have transactions that serve a similar purpose. But, regardless of where that synchronization is, you have to ensure the update logic stays there. Having an interface that loads data, and saves data, at the application layer, ensures that a DB layer lock won't work, either. You have to change it to have the DB actually read and update the data to benefit from the synchronization the DB transaction provides you. So, as I said before...a lock (at the application layer) is neither sufficient nor necessary. A DB transaction (with the implied update of the query necessary to make a transaction mean anything) is both.
- tored 6y ago
  Article talks about two different types locks, one is the mutex, which the article admits won’t work when using with multiple instances. The other is briefly mentioned with a link to Wikipedia and is a optimistic lock that is to be used with your database. I talked about two use cases for optimistic locking, one applied with a database, that with will work with any number of instances, because the synchronization check lives in the database and not in the instance. My other case was to use an optimistic lock instead of the mutex example, that will still only work with single instance because the synchronization check is local to the instance. (Edit: wrong, it could actually work there too, if saveBalance() was changed) Optimistic locking is quite simple to implement, just check that the value has not changed before writing, if it has you have to reread the value again.
- tored 6y ago
  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.

No, locks work. Lock is needed if you need to do some sort of complex computation before writing, like updating a JSON blob.

by tored 6y ago

No, locks work. Lock is needed if you need to do some sort of complex computation before writing, like updating a JSON blob.

lostcolony 6y ago

As both I and the parent said, "If you have multiple instances". In which case, locks (like those mentioned in the article) don't work. Because instance A reads 0, instance B reads 0, instance A writes 50, instance B writes 50. Totally serialized on each instance, totally unpredictable in when they hit the DB. Just like you have a lock serving as a synchronization point on an instance, in the case of multiple instances, you want to push the synchronization point down into a single instance at the data layer (which you often have when using a traditional RDBMS). But RDBMS' don't have locks, per se, for that synchronization; they have transactions that serve a similar purpose. But, regardless of where that synchronization is, you have to ensure the update logic stays there. Having an interface that loads data, and saves data, at the application layer, ensures that a DB layer lock won't work, either. You have to change it to have the DB actually read and update the data to benefit from the synchronization the DB transaction provides you. So, as I said before...a lock (at the application layer) is neither sufficient nor necessary. A DB transaction (with the implied update of the query necessary to make a transaction mean anything) is both.

tored 6y ago
Article talks about two different types locks, one is the mutex, which the article admits won’t work when using with multiple instances. The other is briefly mentioned with a link to Wikipedia and is a optimistic lock that is to be used with your database. I talked about two use cases for optimistic locking, one applied with a database, that with will work with any number of instances, because the synchronization check lives in the database and not in the instance. My other case was to use an optimistic lock instead of the mutex example, that will still only work with single instance because the synchronization check is local to the instance. (Edit: wrong, it could actually work there too, if saveBalance() was changed) Optimistic locking is quite simple to implement, just check that the value has not changed before writing, if it has you have to reread the value again.
tored 6y ago
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.