This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Locking & Exceptions (B&S) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Locking & Exceptions (B&S)" Watch "Locking & Exceptions (B&S)" New topic
Author

Locking & Exceptions (B&S)

Jack Gold
Ranch Hand

Joined: Feb 04, 2005
Posts: 85
I have been testing my locking algorithm and have some questions regarding handling of exceptions within a locked section.

The design uses an Adapter class on top of Data. Data contains a cached list of records, and recNo (position in file) is used as the primary key. Each client has its own copy of Data.

The following code sample shows the bookContractor() method which performs the following:

* lock
* Checks to make sure record is not already booked.
* Updates/books record (More file IO)
* unlock



If the record is already booked, the unlock() method is called and an exception is thrown.

However, my question regards what should happen with IO error which is harder to simulate in testing. If an IO exception is not caught, the unlock method will never be called. The workaround that I see is to put the IO calls in a try catch block, which will catch the IOException, call unlock(), and then rethrow the exception.

Any insight appreciated.

[ July 06, 2005: Message edited by: Jack Gold ]

[ July 06, 2005: Message edited by: Jack Gold ]

[ July 06, 2005: Message edited by: Jack Gold ]
[ July 06, 2005: Message edited by: Jack Gold ]

SCJP 1.4<br />SCJD <br />SCWCD (Studying)
Yevgeniy Treyvus
Ranch Hand

Joined: Mar 09, 2005
Posts: 48
Jack,

I think you're on the right track. Even if an exception occurs, it does not make any sense to leave the record locked. The record should be unlocked in any case to let other clients have a chance at it.

PS: I have been done with my assignment for a few months now, so I am little rusty but I think your method can be simplified a bit. I think that there's no reason in obtaining a lock before making a check to see if the contractor is booked or not -- that's a read only operation.



[ July 07, 2005: Message edited by: Yevgeniy Treyvus ]
[ July 07, 2005: Message edited by: Yevgeniy Treyvus ]

SCJP, SCJD
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
Originally posted by Yevgeniy Treyvus:
PS: I have been done with my assignment for a few months now, so I am little rusty but I think your method can be simplified a bit. I think that there's no reason in obtaining a lock before making a check to see if the contractor is booked or not -- that's a read only operation.


There is a very good reason for obtaining the lock before doing the read: otherwise the following scenario could happen:

client A: read record 1, seems to be not booked
client B: read record 1, seems to be not booked
client A: lock, update and unlock record 1: record 1 is now booked for A
client B: lock, update and unlock record 1: record 1 is now booked for B

The booking of client A has been overwritten, which is of course not allowed. You must lock the record before reading, so that you can be sure that no other client was booking the record while you were looking at it.

To the OP: you could put the unlock in a finally block, so that it will even be done when an exception occurs. You should take care though that you do not unlock the record if it was no locked before (e.g. due to a RecordNotFoundException).

Frans.


SCJP 1.4, SCJD
Yevgeniy Treyvus
Ranch Hand

Joined: Mar 09, 2005
Posts: 48
Yes, I think Frans is right After looking at my code, I appear to be doing the same thing.
Jack Gold
Ranch Hand

Joined: Feb 04, 2005
Posts: 85

To the OP: you could put the unlock in a finally block, so that it will even be done when an exception occurs. You should take care though that you do not unlock the record if it was no locked before (e.g. due to a RecordNotFoundException).

Frans.[/QB]


Thank you. Your suggestion is cleaner than what I had proposed.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Locking & Exceptions (B&S)