Comments on: Persistence and Locking http://pitfalls.wordpress.com/2008/04/07/persistence-and-locking/ Tue, 11 Aug 2009 16:12:23 +0000 http://wordpress.com/ hourly 1 By: apnath http://pitfalls.wordpress.com/2008/04/07/persistence-and-locking/#comment-7 apnath Tue, 08 Apr 2008 09:01:02 +0000 http://pitfalls.wordpress.com/?p=7#comment-7 The approach suggested centralized locking which manages locks, by managing I meant initiating the calls for getting and releasing the locks. The actual locks would be maintained at the db end. The whole idea is to spare individual methods from the locking parlance and decide it at a central level on the basis of flows. For example for two flows: 1. That deposits money into an account 2. Shows account balance We would need to get the account details from the account table, assuming that we wanted to lock the account details while making the deposit in case 1, the centralized manager would help us do so without coding special method for selecting the accounts. The lock obtained by the centralized manager is actually a db lock, in short the centralized manager would decide if the sql to be executed is a "FOR UPDATE" sql or otherwise. It could fit in more locking semantics as the need arises. The approach suggested centralized locking which manages locks, by managing I meant initiating the calls for getting and releasing the locks. The actual locks would be maintained at the db end. The whole idea is to spare individual methods from the locking parlance and decide it at a central level on the basis of flows. For example for two flows:
1. That deposits money into an account
2. Shows account balance
We would need to get the account details from the account table, assuming that we wanted to lock the account details while making the deposit in case 1, the centralized manager would help us do so without coding special method for selecting the accounts.
The lock obtained by the centralized manager is actually a db lock, in short the centralized manager would decide if the sql to be executed is a “FOR UPDATE” sql or otherwise. It could fit in more locking semantics as the need arises.

]]> By: David Otaguro http://pitfalls.wordpress.com/2008/04/07/persistence-and-locking/#comment-4 David Otaguro Mon, 07 Apr 2008 16:44:40 +0000 http://pitfalls.wordpress.com/?p=7#comment-4 The only issue with the idea of "the central lock manager [that is] aware of all the flows and the locks" is that concurrency issues between clustered applications can't be handled by a centralized lock manager unless you're willing to make the centralized lock manager a clustered beast itself, which becomes potentially problematic. The database itself already has an excellent centralized lock manager... rather than locking rows in the actual tables and manipulating the lockmode of the selects, it might be better to use semaphores obtained from a table explicitly for the purpose of controlling locking behavior, for example a table called, LOCK_SEMAPHORES or somesuch. That makes the table the source of lock data (for the application), if necessary you can use the database's utilities for lock manipulation to deal with lock problems, and you can distribute your locking manager with the shared lock state explicitly visible in the locks table. Just a thought. The only issue with the idea of “the central lock manager [that is] aware of all the flows and the locks” is that concurrency issues between clustered applications can’t be handled by a centralized lock manager unless you’re willing to make the centralized lock manager a clustered beast itself, which becomes potentially problematic.

The database itself already has an excellent centralized lock manager… rather than locking rows in the actual tables and manipulating the lockmode of the selects, it might be better to use semaphores obtained from a table explicitly for the purpose of controlling locking behavior, for example a table called, LOCK_SEMAPHORES or somesuch. That makes the table the source of lock data (for the application), if necessary you can use the database’s utilities for lock manipulation to deal with lock problems, and you can distribute your locking manager with the shared lock state explicitly visible in the locks table.

Just a thought.

]]> By: Peter Veentjer http://pitfalls.wordpress.com/2008/04/07/persistence-and-locking/#comment-3 Peter Veentjer Mon, 07 Apr 2008 15:56:21 +0000 http://pitfalls.wordpress.com/?p=7#comment-3 Using an isolation level is declarative form of concurrency control in databases. In most cases using the correct isolation level prevents setting any lock yourself. The database also is the central place where all locks are managed (not some jvm) and the database uses different strategies to deal-with/prevent deadlocks. In some cases using a time out can be enough, but also the inference of a deadlock is done. So when using a database, deadlocks are not my main worry. So the database is a very very advances mechanism for concurrency control. You could even say that in some areas it is much more advanced than Java (for example Multi Version Concurrency Control: MVCC) to improve upon concurrency by providing multiple versions of the same data. Using an isolation level is declarative form of concurrency control in databases. In most cases using the correct isolation level prevents setting any lock yourself. The database also is the central place where all locks are managed (not some jvm) and the database uses different strategies to deal-with/prevent deadlocks. In some cases using a time out can be enough, but also the inference of a deadlock is done. So when using a database, deadlocks are not my main worry.

So the database is a very very advances mechanism for concurrency control. You could even say that in some areas it is much more advanced than Java (for example Multi Version Concurrency Control: MVCC) to improve upon concurrency by providing multiple versions of the same data.

]]>