Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

About the dead lock

 
Ying Ren
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have not seen any requirement about deadlock. Do we need to deal with it?
Ying Ren
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, you will need to deal with deadlock. That's where you will use threads to wait to make sure it gets the lock, and when another user has the lock, then the client will wait till that user is done, then lock it.
Hope that clears it up. If you do a search for lock or unlock you will get a plethora of hits.
Mark
 
Ying Ren
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, Mark
Thank you.
I think it is hard for me to deal with the dead during the lock, anyway, I will handle other dead situation.
try {
lock(rec);
booking.processBooking();
unlock(rec);
}
catch (Exception e) {
JOptionPane.showMessageDialog(null,"Sorry, your booking process is unsuccessful.\n"+
"The reason is: "+e.getMessage(),"Booking Error",JOptionPane.ERROR_MESSAGE);
}
finally {
lock.unlock(rec);
return booking.isSuccess();
}
I have another FlightBooking class to handle the booking and the LockManager for lock which uses the recordnumber and the RemoteDataAccess as argument.
How do you think?
ying Ren
 
Richard Mok
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I use a LockManager in the RemoteData object to lock and unlock. How to solve the deadlock problem when a Client book a flight, it locks a record but some how this Client crashed before it unlocks the record. Is the Unreferenced interface can solve this problem?
Thanks,
Richard
 
Ying Ren
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I changed my mind. Now I use the Timer to handle the deadlock. Every connection will have 1 minutes if the deadlock happens.

YING REN
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I changed my mind. Now I use the Timer to handle the deadlock. Every connection will have 1 minutes if the deadlock happens.

I am not sure you understand what deadlocks are. A typical scenario for a deadlock is when a method that synchronizes on object A calls a method that synchronizes on object B. Now, when another thread that owns the monitor on object B tries to call a method that synchronizes on object A, the deadlock occurs.
If you have such a situation in your code, it indicates a fundamental flow in the design, and you don't want to "fix" it by dropping the client connection.
Eugene.
 
Nate Johnson
Ranch Hand
Posts: 301
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Even if it is not fixing up deadlocks, wouldn't his approach fix things like a client crashing after a lock but before the unlock was called?
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Even if it is not fixing up deadlocks, wouldn't his approach fix things like a client crashing after a lock but before the unlock was called?

It might fix the problem of a client crashing, but that fix might also mask the *real* deadlock (if there is any). I am just pointing the difference between the deadlock occuring because of the stale client and the deadlock occuring because of the improper use of synchronization.
Eugene.
 
Charles Miller
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I also wondered about whether to apply leasing to the locks (ie, have them timeout) to handle the potential client crash. However, I did not implement that in my code because the instructions on the lock() method indicate that there is no timeout and that the call blocks until it can achieve the lock. I figure it is better to follow the directions and make a note of the issue in the design doc than it is to not follow the directions.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm with Charles: I don't think the you'll go wrong if you adhere to a strict interperation on the requirements. To me, "no times outs apply to this method" is pretty strong.
JM2C,
M
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic