This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
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.
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?
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).
synchronize on HashMap of record numbers/cookies
see if it's already locked and if it is
if it's not locked
go ahead and put the key/value pair into the static HashMap
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!
Joined: Aug 29, 2005
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.