How to deal with a client crash during locking

Hi all I'm doing the B&S assignment & was just wondering - what is the best way to deal with a client crashing while it is getting a lock on the database? Or for example, crashing just after it gets the lock and before it actually books or modifies a record?

The two main approaches I can see are : a) Use an RMI callback to see if the client is still alive, if not then allow other threads to get the lock

b) Create a timer thread that will detect if a client has held a lock for too long (say for 30 seconds or more).

Or is it necessary at all to cater for this situation? It seems like something you could lose marks on if you don't check for it.

Hi, I am not sure how you have designed your application. I am also not much aware about B&S assignment. But I can suggest one. For me my remote server provides a service. As a client to remote server I am not bothered about locking/unlocking. In other words I request for a service to remote server. Remote server internaly acquires lock then performs the activity & then unlocks the record & then provides me the final result. So the request is atomic in nature.

Why would you want make remote calls over lock/unlock? I feel its inefficient to make so many remote calls. Just one call, it takes care of everything.

Hi That's a good idea. At the moment I am calling lock() from the client, the server locks the record, I then call modify from the client (to book the record or whatever), and then I unlock - again from the client.

There is no reason (I think anyway) why it couldn't be atomic on the server - it's just that the DB interface provided by Sun does specify lock() and unlock() methods, so I presumed it would be best to implement it like this....?

The problem is if you do make remote calls over lock/unlock, the client could crash just after locking (theoretically) leaving the record permanently locked.

From a design perspective I think it is good to have it all server side though - i'm just a bit wary of going against the interface!

I have done a similar approach as archana. I have the B&S assignment and has a higher level 'data modificator' on the server side. I only return serialized value objects to client, not anything directly from Data.java. The assignment only states that Data.java has to be the data access class, and don't say that this has to be communicating with the client.

I have done a similar approach as archana. I have the B&S assignment and has a higher level 'data modificator' on the server side. I only return serialized value objects to client, not anything directly from Data.java. The assignment only states that Data.java has to be the data access class, and don't say that this has to be communicating with the client.

So thinking this way would be possible to have one class calling update, on the server side and another class in the server side calling the lock, update and unlock.... Then returning the result as true or false.. or something like, is that what you are saying ?

The Death of one is a tragedy, but the Death of a million is just a statistic. Joseph Stalin

worrying about client crash during locking is a problem ONLY when you are calling lock/unlock from client.
Make client request the server to book a record, and let server take care of locking/unlocking: In this case it won't matter even if the client crashes.
and specifications don't stop from doing this.

I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com