I've literally read hundreds of posts on locking/unlocking, and have crunched it down, hashed it out, and believe that I almost have it licked, save one nagging problem. I am using the popular "RMI Connection Factory" method to solve my remote networking issues, and added a global LockManager to the factory to manage ALL locks from ALL clients. Each ConnectionImpl gets a reference to this global LockManager. Mark has mentioned clients that track their own locks with a local HashSet (or other mechanism) in the ConnectionImpl objects. The implication is that both methods should be used in tandem to provide proper locking. Is this correct? Should each Connection object have a local LockManager to manage its own locks, and then a reference to a global LockManager, so that it can make its locks visible to all clients? Almost there..... Thanks in advance!
Good Question Jason. I am waiting for the answer too. I wish I had had a LockManager. I think the way that most people used it was to use the record Number as the Hash and the Connection Object as the stored object in LockManager. This way the Connection object just calls lock(Integer recordNumber, Connection clientID) and unlock(Integer recordNumber, Connection clientID) Then you don't need my solution of each Connection Object having it's own HashSet. But then I could be wrong here, and would like others who have implemented the LockManager to answer, as they would be better equiped to answer. So I am waiting too. Mark
Jason, I've implemented the Lock Manager as a shared resource for all locks held by all clients as you mention. The Lock Manager identifies the owner of the lock by some object (for example, the connection object). There is no need for the client to track the locks themselves as well. I think you've just mixed two different (albeit similar) approaches and that's what is causing the confusion.
I would go with global LockManager to handle all the clients. My LockManager was a Singleton with a static ArrayList that holds the instances of Lock. Lock is a class that contains, remote instance, record number, db file name, and the timestamp when the locking took place. This Lock class is also responsible to compare the locks. LockManager delegates the comparison of locks to this Lock class. Here is the flow: Remote Data Instance(Connection) -> LockManager(uses Lock instance) ->Data
Joined: Feb 11, 2002
Originally posted by Sai Prasad: I would go with global LockManager to handle all the clients. My LockManager was a Singleton with a static ArrayList that holds the instances of Lock. Lock is a class that contains, remote instance, record number, db file name, and the timestamp when the locking took place. This Lock class is also responsible to compare the locks. LockManager delegates the comparison of locks to this Lock class.
Sounds similar to mine, except my Lock Manager isn't a singleton. IMHO it is better to have a Lock Manager instance per db file if that is what you require. That way the Lock Manager can be re-used for purposes where there isn't a 'db file'.
Joined: Feb 25, 2002
Originally posted by Steven Sloggett:
That way the Lock Manager can be re-used for purposes where there isn't a 'db file'.
If you don't have a db file and say use a RDBMS why would you need a lock manager?
Joined: Apr 02, 2002
Thanks guys. I was having trouble convincing myself as to the use of client-side locking. It just doesn't seem to belong there, but rather on the server. Also, I don't think that I will make the Lock Manager a singleton. Peter has successfully convinced me of the evils of singleton overuse. My client-side and server-side factories are singletons. That's enough for me. I really want to give props to Mark and Peter. Almost every stumbling block that I have encountered during this cert has been solved by searching this forum, and the best (or at least the most lucid) explanation is always contained in a post by Mark or Peter.