File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes How to deal with a client crash during locking Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "How to deal with a client crash during locking" Watch "How to deal with a client crash during locking" New topic
Author

How to deal with a client crash during locking

ciaran_cahill
Greenhorn

Joined: Oct 01, 2007
Posts: 5
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.

Thanks!
archana kher
Greenhorn

Joined: Oct 04, 2007
Posts: 16
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.
Joe O'Keefe
Greenhorn

Joined: Oct 01, 2007
Posts: 4
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!
Anita S�rensen
Greenhorn

Joined: Oct 17, 2007
Posts: 11
I don't think this is a problem.

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.


SCJP - done, SCJD - ?
Matheus Mendes
Ranch Hand

Joined: May 15, 2007
Posts: 66
Anita S�rensen wrote:I don't think this is a problem.

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

SCJP 6.0, SCJD
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2268
    
    3

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.


I didn't worry about it... but addressed this situation in my choices.txt file, and said that, since the specifications did not mention such situation, I didn't face this as a problem.


Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
Alain Dickson
Ranch Hand

Joined: Dec 08, 2008
Posts: 53

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.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: How to deal with a client crash during locking