[Logo]
Forums Register Login
Locking & Exceptions (B&S)
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 ]
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 ]
 
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.
Yes, I think Frans is right After looking at my code, I appear to be doing the same thing.
 

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.
Wink, wink, nudge, nudge, say no more ... https://richsoil.com/cards



All times above are in ranch (not your local) time.
The current ranch time is
Dec 14, 2017 03:19:25.