Persistent Locking

Question

Just to warn you before anybody reads this long post and finds it completely out of his/her interest - in this post I'm sidetracking a bit from the 'traditional' Java concurrency...
I am currently interested in the subject of persistent locking, i.e. acquiring locks in database. Last year I was involved in several projects with such requirement, mainly on account of running in clustered environment. In such case there is sometimes a need to ensure that a resource / critical code block is subject to synchronized modification / execution beyond the scope of a single JVM. As far as I know, database vendors offer different kinds of locks, but they all are bound to a single transaction (this is also reflected by ORM APIs, which often expose lock() methods that lock an entity till the end of current transaction). However, the usecases that I encountered required different scopes:
- 'smaller' than a single transaction (e.g. small block of code that required cluster-wide synchronization within larger transaction executed frequently - transaction-scoped lock would hurt scalability, since each transaction would be blocked at entry point to the critical code block until the one holding the lock would finish)
- 'greater' than a single transaction - e.g. possimistic locking of data objects for certain page flows consisting of multiple web pages (= requests = transactions) for current user. If another user tried to enter the page flow, he would be informed that someone else is modifying the data and he must try again later (this usually does not fit for mass-user internet portals, but does occur in internal entrprise apps)
I am trying to design small framework / library that would handle such use cases in a generic way, thus making implementation of this kind of locking easier. But I don't see much discussion around this particular topic (in fact, I don't see any discussion and I wonder, if I'm the only person out there that has met such use cases... Probably app server vendors provide their own solutions for cluster-wide locking, presumably in some cleverer way than database locks, but the projects I participated in usually operated on simple, unmanaged clusters (actually 'cluster' is a wrong name for this, they were simple collections of machines hidden behind load-balancer). So this kind of solution (vendor-specific) was not an answer, because it would require a full-blown cluster.
My question is therefore - have you ever met the kind of scenario I described - where persistent locks would be useful? If so, please describe it. I don't want to do anything basing exclusively on my experience. It would help me a lot to get to know various points of view and to convince myself that this kind of locking is useful in more scenarios.

Answer 1

Hi Rich,
1 more question .. if i have multiple Db tables related to 1 logical entity (eg Logical entity is customer and it has multiple Ztables to store customer's data) so I would have to create a persistent class for each of the Ztables correct ? then which of the following approaches is the best
1. Write a wrapper class to represent the Business entity customer and inside that wrapper class call the locking methods and the GET_  & SET_ methods
2. Add the other persistent classes as attributes of the main persistent class( as type ref to so that its corresponding GET_, SET_ methods are auto generated ). eg. IF the are two tables ZCUST, ZCUST_COMP_CODE then we would have 2 persistent classes. Should I add the persisent class of ZCUST_COMP_CODE to ZCUST ?