• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

lock manager design

 
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The lock manager I'm going with is very much like the code seen in threads related to the topic, but there are some differences in how I'm going about the design of the lock manager...
I've got a DataSource and a Lockable interface.
DataSource is all the db-related calls
Lockable is lock and unlock. My eventual flavors of Data will implement both.
LockManager deals with Lockable objects.
I've got a LockManager interface and plan to have a MultiUserLockManager and a SingleUserLockManager. The managers deal with a Lockable.
There is a static getInstance(Lockable) method that lets whomever get a manager. Current implementations return a new manager if the given Lockable is not already associated with a manager (in a private static map), or an existing manager if the given Lockable already has a manager.
SO... the crux of the issue: the LockManager interface has lock(Object, int) and unlock(Object, int). I'd like to enforce the implementation of the static LockManager getInstance(Lockable) factory method.
Presently, I've got an AbstractLockManager class with a stub factory method that throws an operation unsupported exception. The two manager implementations have real factory method impls that override. Is this a kludge? Feels like one. What is the best practice for making sure a static factory method is part of the interface of subtypes?
All this seems worthwhile: the factory method with private constructors allows for tweaking the behavior behind the interface. For now, I want 1:1 relationship between Lockables and managers. But other impls could do something different behind getInstance().
Thanks in advance for feedback and insight.
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I've got a LockManager interface and plan to have a MultiUserLockManager and a SingleUserLockManager. The managers deal with a Lockable.



Huh? Why two, isn't a lock manager to handle multiple "Threads" from causing deadlocks or other problems. So what is the difference between SingleUserLockManager and MultiUserLockManager.
A LockManager's purpose is to handle locks, and in this case it doesn't care about number of users or threads.
As we have seen in other posts, they lock in local mode, so they would also lock in single user, single thread, never any possibility of any kind of contention. In all cases there is only one LockManager needed.
Mark
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've made a mess of lock management...
This 2 lock manager thing was aimed at dealing with the differences in lock behavior when working with local vs. remote data sources.
I was not going to have locking when working with local, but have now started to waffle on that decision based on reading other discussion threads.
The local manager would call lock and unlock in Data, but not track the calling client object. The remote manager would do both.
 
Mark Spritzler
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you still want to lock in lock, it would still be OK to have the LockManager track the client like it does in remote mode.
But, my preference is still no locking in local mode.
Mark
 
We cannot change unless we survive, but we will not survive unless we change. Evolving tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic