Hi everbody, Concerning locked records I've got a question with a scenario as the following: We're in the network modus, with two gui client connected to the network server (does not matter if implemented as tcp/ip socket or rmi): - Client A locks a record for updating. - Client B tries to get a lock and goes to the wait() until client A does a notifyAll(). - Client A's user is typing some information on his GUI to update the record (while holding the lock at the same time). now theoretical this client could lock the record for an indefinite time. - And the gui by client B is still trying to get a lock for this record, while for example showing an indeterminate progress bar. One approach would be to let the user B to press a Cancel button on his GUI, as soon as he finds out that the record is locked too long, but at the meantime we've invoked the lock() method already, and have no way to call cancelLockRequest() in an asynchronous manner (as far as DBAcess interface does not/should not provide such a method). How could one solve this problem? Thanks for any comment. By the way, I forget to mark the topic with NX: prefix, as I'm also one of those folks trying to achieve this certification challange, so sorry for inconvenience. [ December 06, 2003: Message edited by: Markus M�ller ]
Markus, Let the force be your guide . This problem cries out for a 3-tier solution. Don't give the client a chance to do this. Handle the lock-update/delete-unlock all within the context of a single method call on the server side. To the user it's all just one operation anyway. Clouded the path to the darkside is.
kktec<br />SCJP, SCWCD, SCJD<br />"What we observe is not nature itself, but nature exposed to our method of questioning." - Werner Heisenberg
Hi Markus, What Ken's solution does is ensure that the call to lock() happens immediately before the call to update(). Therefore there will be no time spent waiting for user input, and your initial scenario cannot happen. However you do not need to change to a three tier (thin client) solution to achieve this - in a fat client solution you can also have your call to lock() immediately before your call to update(). This may give you more flexibility in the future, and depending on you instructions may even be a closer fit to the requirements. In case we are confusing you with this talk of two tier (fat client) / three tier (thin client), take a look at "Should lock methods be callable by the client". As for your initial question: I don't think it is necessary to provide any means of cancelling a booking mid way through a transaction. It would be nice in real life, but it is difficult to do it cleanly given the current instructions. If you feel that you must provide some way of cancelling the booking, then I would have a separate thread handling the booking. You could then provide the GUI with a dialog box telling them that the transaction is in progress (along with a cancel button) and if the user hits cancel, you just set a flag in the booking thread to tell it to cancel the transaction when it (finally) gets the lock. Regards, Andrew