• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Clarification on lock tracking

 
Jason Boutwell
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Steven Sloggett
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Sai Prasad
Ranch Hand
Posts: 560
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 560
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic