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.
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
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.