• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Tim Cooke
  • Devaka Cooray
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Piet Souris
  • Mikalai Zaikin
Bartenders:
  • Carey Brown
  • Roland Mueller

Persistent Locking

 
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am currently interested in the subject of persistent locking, i.e. acquiring locks in a 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 provide lock() methods that are bound to current transaction). 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 a framework 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 more clever way than database, 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.

My question is therefore - have you ever met the kind of use case I described - where persistent locks would be useful? If so, please describe it. I don't want to do anything basing on 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.
 
What could go wrong in a swell place like "The Evil Eye"? Or with this tiny ad?
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
reply
    Bookmark Topic Watch Topic
  • New Topic