File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Problem with lock manager

 
Denis Spirin
Ranch Hand
Posts: 72
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi
I m going to download assignment soon, and I tried to write lock manager now - as I understand this is one of most difficult problems.
Well, I wrote it, but the question is : why does it work?
Locking is processed completely on server side, no cookies are passed to client.
Here is pseudocode for LockManager. Its methods lock() and unlock() are called from
remote database implication. LockManager is a singleton. Every client gets a reference to
RemoteDatabase object (and this is one-to-one relationship). LockManager instance is static
member, and therefore clients perform concurrent sequental access to records (lock/modify/
unlock).

Its advantage is that I can test it from the same computer, starting 100 threads which
connect to server using IP, not localhost. every thread gets its own ID.
It is fine, but when I start it in 2 cases from 5 (approx) I get deadlock. Here is a part of log file:

.....
388 trying to unlock ...388 unlocked record
Locking by 378
378 trying to unlock ...378 unlocked record < ------------ 378 called unlock()
Locking by 353
353 trying to unlock ...353 unlocked record
Locking by 376
376 trying to unlock ...376 unlocked record
Locking by 309
Client 346 is checking if locked, lock belongs to 309
346 is waiting
378 trying to unlock ...378 unlocked record < ------------378 called unlock()
<EOF>

Here numbers are parts of IDs (just substrings of "RMI TCP Connection(<number> - <my ip>" which is returned by Thread.currentThread().getName()).
Notice that client 378 called unlock twice! Thats not a bug - all calls to unlock() are made only once, and anyway it happens sometimes, but not always.
This is a puzzle for me. Again, notice, that before second call lock owned by 309. But 378 anyway unlocks it !!! Then program hangs.
I put System.gc() in lock() method (see label 3 in pseudocode above) and deadlock disappeared. It works fine. I tested it with 100 clients more than 30 times - no problem. Log file is ok, clients wait, lock, unlock etc in sequental order.
Now, I cant get whats the reason for deadlock? Why did GC made it work ?
System.gc() is the thing that I dont want to use in assignement; I think it should not be used.
Second, currently I cannot test LockManager from different computers. I use "loopback" calls
from the same machine. How do you think, will this program work in real multiuser environment? I mean - I use current thread as ID. Will it work?
I think yes, but it would be much more useful to hear your opinion.
Thanks
 
Satish Avadhanam
Ranch Hand
Posts: 697
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Denis, very welcome to SCJD forum.
You are working on the locking before you even downloaded the assignment? This is real dedication to doing the project. Appreciate it
All I can say is that we cannot depend on the garbage collector. Suppose in your case, you were saying once you included System.gc() its working else not. Then I think it is better to look it or approach the problem in a different way rather than depending on System.gc() only.
Good Luck.
 
Philippe Maquet
Bartender
Posts: 1872
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Denis,
Welcome to JavaRanch and this forum.
Are you calling the lock()... unlock() methods from the *same* method?
I ask you that because RMI does not guarantee that two methods on the same remote object will execute in the same thread.
It means that identifying locks owners by Thread.currentThread() is a valid solution *only* if both lock() and unlock() calls are done within the same method. Something like:

Regards,
Phil.
 
Denis Spirin
Ranch Hand
Posts: 72
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for replies!

Are you calling the lock()... unlock() methods from the *same* method?
I ask you that because RMI does not guarantee that two methods on the same remote object will execute in the same thread.
It means that identifying locks owners by Thread.currentThread() is a valid solution *only* if both lock() and unlock() calls are done within the same method. Something like:



Yeah!!! You are right! I just removed all lock - unlock()s from client side; now these methods are
called from setValue() on server side - it increased speed (only one remote call instead of 3)
and there are no deadlocks now (at least after 15 tests with 100 clients) - without garbage collection.
Cheers!
 
Theo van Loon
Ranch Hand
Posts: 71
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi where is the lockcookie or isn't that part of your exam?
 
Philippe Maquet
Bartender
Posts: 1872
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Theo,
Hi where is the lockcookie or isn't that part of your exam?

Not all versions of the assignments have lock cookies.
Regards,
Phil.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic