SCJP, SCJD
Originally posted by Jethro Borsje:
Your Thread2 should never have acquired the lock on recNo 1....
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
My personal opinion on your second question - as long as your deleteRecord and updateRecord methods meet the contract of the interface, then any automated testing can only test to that contract. Since the interface's contract does not allow for the record to become unlocked following an update, any automated tests would have to assume that it is still locked following the update.
Oracle Certified Master Java SE6 Developer(SCJD),
OCE JEE 6 JSP and Servlets Developer,
Java EE6 Java Server Faces Developer.
Do you also think that the deleteRecord should not unlock the record ?
Then the unlockRecord will fail in any case after the record is deleted.
Calling unlock on a deleted record is a nonsens in my opinion. What do you think ?
Originally posted by Liviu Carausu:
Do you also think that the deleteRecord should not unlock the record ?
Then the unlockRecord will fail in any case after the record is deleted.
Calling unlock on a deleted record is a nonsens in my opinion. What do you think ?
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Oracle Certified Master Java SE6 Developer(SCJD),
OCE JEE 6 JSP and Servlets Developer,
Java EE6 Java Server Faces Developer.
Originally posted by Andrew Monkhouse:
So leaving the record locked is fine, as long as you notify any clients waiting on the thread that they should try to get the lock again (at which point they should get a RecordNotFoundException or similar).
Try 100 things. 2 will work out, but you will never know in advance which 2. This tiny ad might be one:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|