aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Clarification on lock tracking 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 "Clarification on lock tracking" Watch "Clarification on lock tracking" New topic
Author

Clarification on lock tracking

Jason Boutwell
Ranch Hand

Joined: Apr 02, 2002
Posts: 40
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!
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

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


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Steven Sloggett
Greenhorn

Joined: Feb 11, 2002
Posts: 15
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.


Steven
Sai Prasad
Ranch Hand

Joined: Feb 25, 2002
Posts: 560
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
Steven Sloggett
Greenhorn

Joined: Feb 11, 2002
Posts: 15
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'.
Sai Prasad
Ranch Hand

Joined: Feb 25, 2002
Posts: 560
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?
Jason Boutwell
Ranch Hand

Joined: Apr 02, 2002
Posts: 40
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.
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

Thanks Jason, and now I know that the LockManager is the only place that needs to handle the list of locks. I was unsure of that before.
And Sai I like your Lock class.
Mark
Steven Sloggett
Greenhorn

Joined: Feb 11, 2002
Posts: 15
Originally posted by Sai Prasad:
If you don't have a db file and say use a RDBMS why would you need a lock manager?

You wouldn't. I still wouldn't have Lock Manager as a singleton in any case.
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

I would know that my code would only have one instance of the Data or LockManager because my code would only create one of them. I would have no need to make them a Singleton.
Mark
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Clarification on lock tracking