aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes lock manager design Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "lock manager design" Watch "lock manager design" New topic
Author

lock manager design

Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
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.
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17257
    
    6

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


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
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
Sheriff

Joined: Feb 05, 2001
Posts: 17257
    
    6

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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: lock manager design