Network fails after lock is granted

[Mike Hays]

What should happen if there is a network problem as the lockCookie is returned to the client? The client does not receive the cookie but the Data server has the record locked for that client. The record is locked but is not accessible to anyone. I'm just getting started thinking about networking so I'm not sure whether the server will get notified that there was a problem.

[Roberto Perillo]

Howdy, Mike!

Champion, this is a situation that you may or may not want to consider. I myself didn't consider such situation. Another situation I didn't consider is when the client crashes right after locking a record. Since handling these scenarios is not a must, I just justified that it was pretty likely that these things would never happen, so I didn't worry about it. You may want to come up with a locking timeout or something, but that isn't really necessary. This is a matter of choice: whatever is yours, justify it and you should be fine!

[Andrew Monkhouse]

While I agree that this is not something you need to implement, I think it is something you should consider (as you are obviously doing). Should you decide not to implement any handling for these sorts of errors, I think it is a good idea to mention that in your design decisions document.

I am not sure about a locking timeout on the server side - my reading of the instructions seems to imply that once a record is locked by a client then it remains locked until the lock is explicitly released. If I had to solve your initial problem, then I would probably look at two things:

what error (if any) is going to be seen server side if the transmission of the lockCookie to the client fails? Can this be caught and one (or more) retries be sent?

does it make sense to have a client side timeout to handle this? I definitely recommend against this in your real project, as it is going to make the project far more complex for little gain (especially since the first point should handle your particular error anyway). You would then have to consider what happens if the client times out and then later the server fulfills the lock request. You would also have to consider how to handle multiple requests from the same client to lock an individual record (you probably have to consider this anyway).

Likewise with the second scenario that Roberto mentions: the client crashing or the network connection being dropped while locks are being held - you do not need to develop code for this. But if you do want to do this, it is easy enough to do. A TCP/IP Socket connection is trivial - you simply catch the disconnection exception for a given client and unlock any outstanding record locks they have. RMI is a tiny bit more complex - you need to create an RMI factory so that each client get's their own Remote class which can then implement Unreferenced. When the client disconnects you can again unlock any outstanding locks.

The solutions to the second issue could also be used as a potential resolution to some of the problems listed in the possible solutions to the first issue - if a client side timeout occurs then it could manually disconnect from the server, request a garbage collection (so the distributed garbage collector will hopefully be run), thereby releasing any locks that might have been granted.

All of which is getting a little complicated. As Roberto mentioned, you do not need to do any of this. You can get a perfect score without coding for any of these issues. The problem you are then faced with is - do you code a "better" solution, knowing that the more code you add, the more chances you get to make some trivial mistake that might actually reduce your score?

[Mike Hays]

Thanks for the helpful answers guys. I'll see if I can detect an error like this on the server and remove the lock. If not, I'll ignore the problem and mention it in my choices document.