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

Question on Roberto's Famous Locking Test

 
Anne Crace
Ranch Hand
Posts: 223
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I tried commenting out the unlock line (plus I added a println that says 'getting ready to deadlock') 1 line ahead of it. Well, I'm using Eclipse, and it appears to complete (no red square). I used to get the red square all the time until I fixed my code. I'm doing my final checks and sure don't want to have a locking issue. I'm wondering if it's because I'm using a Singleton for Data, or by unlocking in a finally block in my lock method. The last line that prints is the "getting ready to deadlock" line. Just curious if anyone else experienced this or has an explanation.
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Greetings, Anne!

Well, I'm using Eclipse, and it appears to complete (no red square).


Even with the call to unlock commented?

I'm wondering if it's because I'm using a Singleton for Data, or by unlocking in a finally block in my lock method.


So, in your lock method, you have a call to the unlock method? I'm not sure if I understood correctly how your code is structured... could you please post a pseudo-code so we can have an idea of how it is structured?
 
Anne Crace
Ranch Hand
Posts: 223
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I actually added the finally block today at work, so I still have the old one at home. It runs and completes at home too. (I'm there now and just re compiled and ran it). I use a LockManager class. My Data (facade) to my DataFileAccess(singleton), just does checks for deleted record and I compare TotalRecords.length against the record number to make its not greater than the highest record number or negative (invalid record either way). Here's some pseudo of my lock/unlock (without the Finally).
Lock:
createCookie
synchronize on HashMap of record numbers/cookies
see if it's already locked and if it is
try
wait
catch Interrupted
if it's not locked
go ahead and put the key/value pair into the static HashMap

Unlock:
synchronize the HashMap
while the record number is in the HashMap
if it is, do a get on recordNumber and check the cookie returned with equals(cookie)
if it passes that test, go ahead and remove it from the HashMap
NotifyAll
if the cookie doesn't equal lockCookie, throw SecurityException

I'll let you take a look at that before figuring out the finally thing. I've seen quite a few posts that it is a good idea to always unlock in finally. I did a major search on Locking and logical locking today! Can you take a look at the doubleLock and wait thread? I think his code is basically right, but I haven't passed yet, and you aced the Locking part, so should be able to tell right away if it's OK. Thanks!

 
Anne Crace
Ranch Hand
Posts: 223
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I ended up removing the finally block from my LockManager. My Data class has finally blocks that call unlock in both Update and Delete, so that would have been redundant. My Data class has a static instance of my LockManager class. LockManager pretty much does cookie generating, and logical locking. as explained in the previous post. I synchronize the whole database in all methods of the DatFileAccess class.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic