• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Locking Issues

 
Stephen Loh
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just wondering, if my Data class implements the given DB interface, can I leave out the lock and unlock methods (meaning empty implementations)? The following quote is from my instructions:

Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above.


Do I take it that empty implementations are not allowed? Or does the quote merely mean that locking is mandatory, but the solution you use is not important (i.e. you can use another class to handle the locking and leave the locking methods in the Data class empty)?

My current issue here is that every client gets his own Connection object which delegates requests to the one and only Data object. For the lock and unlock methods given to me, they only accept the record number and cookie (for unlock) as arguments. This prevents me from registering the Connection object to the LockManager. Or am I missing something?

Any advice on this problem? Of course, I will definitely prefer a solution that does not provide empty implementations of the locking methods, unless I've really got no other alternatives.
[ April 21, 2005: Message edited by: Stephen Loh ]
 
Frans Janssen
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Stephen,

You must implement the lock and unlock methods. Even if you can solve concurrency issues differently, failing to implement lock and unlock will have you fail your assignment. See this thread.

If your interface uses the cookie mechanism, I advise you do use the cookies to solve the concurrency issues. The interface given to you by Sun is more than just a hint how you might solve things (remember: you must implement the given interface).

You can of course implement the internals of the locking mechanism in another class if you need to, but consider the given interface as the portal to that functionality: all calls from the client must at some time pass the (class that implements the) interface.

Frans.
 
Stephen Loh
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you very much for your advice. I have to admit that I fully agree with you. Looks like I better go back to the cookie mechanism.

However, I have a doubt. I understand that the purpose of the cookie is to identify the client who locked the record. But the thing is, if the client crashes before he unlocks the record, how should the unreferenced() method (assuming I'm using one) perform the cleanup? In order to unlock the record that the now-defunct client locked previously, you need the cookie. BUT, the client is gone, so now there is no one to provide the cookie to the unlock method.

One way to get around is to store a copy of the cookie in the Connection object. But I find this a severely bad move. This defeats the purpose of the cookie. If I can store it there, why should I bother to send the cookie to the client? I may as well just provide business methods in my RMI interface without exposing the locking mechanism.

Any suggestions?
[ April 21, 2005: Message edited by: Stephen Loh ]
 
David Sham
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am having a similar concern. The Exam Cram book by Alain Trottier addresses the problem of a client dying before unlocking a record. His solution was to send the client into the LockManager's lock() method and then instantiate a WeakReference using the client object. This way, if the client dies before unlocking a record, the WeakReference containing the client object will be garbage collected. That should cause the WeakReference containing the client to go away. Then any threads waiting can check the lock hashtable that contained the WeakReference for a null reference. If a null reference is found for the locked cookie, then remove the locked cookie from the lock hashtable and continue with locking for the current thread.

I have one question about this approach: in the Exam Cram book the "client" passed into the lock() method in the LockManager is actually the RMIImpl reference. The RMIServer instantiates only 1 RMIImpl reference. This RMIImpl reference provides access for remote objects to the database through RMI. If the RMIImpl is the "client" reference that is being passed into the lock() method of the LockManager and there is only 1 RMIImpl reference instantiated in the RMIServer, then how is it that if a client's JVM dies that client's reference will be garbage collected? I do not understand how the Exam Cram book says the "client" is garbage collected when it is the RMIImpl reference being passed into the LockManager's lock() method (not the client's reference). Am I missing something or is this how RMI works?

Any input is appreciated. Thanks.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12007
215
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi David,

You might want to take a look at this thread. In it there is a discussion on the problem with the Exam Cram solution, and some hints on how to solve it.

Regards, Andrew
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic