How to implement dead-lock recovery?

[Patrick Cobbett]

When should dead-lock be discovered? Should a call to lock a record detect immediately if it will cause dead-lock? If so, should it then throw an exception? The method signature is already given to us (FBNS):
public void lock(int record) throws IOException
Does enabling dead-lock recovery mean that we have to alter the contract as specified in the requirements?
Any one have any ideas?

[Marcos Motta]

Patrick,
I dont think you should bother with dead-lock, unless otherwise stated in your assignment instructions.
It is not an issue for the lock();modify();unlock(); sequence required to book a seat.
Marcos

[Andrew Monkhouse]

Hi Patrick
If you do decide to implement deadlock checking, then it would have to be done immediately that a call to lock is made.
If you did decide to ignore the lock request because it will cause a deadlock, then you could throw an exception that is a subclass of IOException.
Regards, Andrew

[Bob Reeves]

Hi Patrick:
I think a good design is free of deadlock by methodology, not by deadlock detection and release. For example, one generally accepted stratedgy to avoid deadlock is to acquire resources in a defined order, which must be followed by all resource acquire methods (i.e., the methodology). An example might be: always acquire the LockManager first, then acquire one of the locks that it supervisers.
Tx

[Max Habibi]

I agree with Bob that you want deadlock avoidance, not recovery. However, I don't agree( with Andrew) that throwing a subclass of IOExcepion is the best way to communicate non IO issues.
The professional grade solution here would be to add a data.checkLock method that returns the state of the lock. However, that might be overkill.
All best,
M

[S Bala]

When is deadlock possible. In the ULRyBird 1.1.3 assignment, the interface allows modifications to only a single record at any time. So, the client won't be able to make multiple reservations at the same time.

[Mark Spritzler]

Originally posted by S Bala:
When is deadlock possible. In the ULRyBird 1.1.3 assignment, the interface allows modifications to only a single record at any time. So, the client won't be able to make multiple reservations at the same time.

That is true.
Also if you follow the lock-read-modify-unlock process of "Booking" and that is the only time you will lock a record. Then the release of the lock happens quickly for the client, lessen the chance for a deadlock, if not just removing the posiibility when the client would in these cases only ever have one record locked.
Mark

[Philippe Maquet]

Hi everybody,
Interesting thread ! The first one - if I can recall - in which I cannot agree with any of the writers ! (I mean except for the initial question).
Let's start with it :
Patrick
When should dead-lock be discovered? Should a call to lock a record detect immediately if it will cause dead-lock?

Yes

Immediately

Patrick
If so, should it then throw an exception?
Yes, because it's the only valid way to communicate this abnormal situation to the caller.
If your specs state that the lock method is a "void" method, your have no choice, and if your specs require to return a cookie value, you cannot reserve for the latter some special "deadlock" cookie value.
Patrick
The method signature is already given to us (FBNS):
public void lock(int record) throws IOException
Does enabling dead-lock recovery mean that we have to alter the contract as specified in the requirements?
No. As a SCJP, you already know that implementing an interface brings exactly the same constraints as overriding a method as far as exceptions are concerned : you must not throw new or broader checked exceptions.
It means that you may throw such a DeadlockException extending RuntimeException without breaking the contract. I would document it in the @throws javadoc clause in such a way that a careful user of your class will have the choice to decide or not to catch it (as the compiler will impose nothing).
Marcos
I dont think you should bother with dead-lock, unless otherwise stated in your assignment instructions.
I do think you should bother with any common sense not expressly stated in your assignment instructions. Each time you have to synchronize on some object(s) (which is not expressly stated in your instructions), you do bother with deadlock (anyway, I hope so). So I cannot find any good reason to not be as careful with the database locks which are in the instructions. Remember that from the customer's point of view, when a program "hangs", it simply hangs, whatever the cause.
Andrew
If you did decide to ignore the lock request because it will cause a deadlock, then you could throw an exception that is a subclass of IOException.
IOException is a checked exception, and has nothing to do with a deadlock situation. Even exception chaining wouldn't be appropriate IMO (mess in the caller's code to isolate the deadlock situation from other causes through getCause()).

Bob
I think a good design is free of deadlock by methodology, not by deadlock detection and release.
To be free of deadlock by methodology means scattering responsibilities.
Bob
For example, one generally accepted stratedgy to avoid deadlock is to acquire resources in a defined order, which must be followed by all resource acquire methods (i.e., the methodology).
Yes. It's just what I meant. If you need multiple locks, you just have to sort the recNos before locking ... and if those locks implie multiple tables, you just have to make sure that the locks are asked in some predefined table order too. Don't forget to pin the tables list on all walls in the office to make sure every programmer may refer to it . I hate classes whose well-behaviour depends on smart callers.
Max
The professional grade solution here would be to add a data.checkLock method that returns the state of the lock. However, that might be overkill.
Overkill ?! It's a minimum, isn't it ? And even if you do, responsibility is still scattered.
S Bala
When is deadlock possible. In the ULRyBird 1.1.3 assignment, the interface allows modifications to only a single record at any time. So, the client won't be able to make multiple reservations at the same time.
You are 50% right IMO. The interface lets you lock as many records as you want, update the same number of records and then unlock them, while the instructions state that you must be able to book a selected record. So, from the application-writer point of view, it's OK, you don't need to update more than one record at a time. But :

As the Data class writer, you must to conform to your DBAccess interface which allows much more.

As the application writer, you may expect this little transactional improvement : to be able to book two given rooms/nights together, or none of them.

Dealock prevention is a so common need and touches so much the locking design foundations, that you cannot postpone it (except if you are willing to redesign-rewrite the whole locking stuff).
Mark
Also if you follow the lock-read-modify-unlock process of "Booking" and that is the only time you will lock a record. Then the release of the lock happens quickly for the client, lessen the chance for a deadlock, if not just removing the posiibility when the client would in these cases only ever have one record locked.
I have no further comment than already written above.
Hey guys, I just found the best way to quickly make 1..2..3..4..5..6 new friends !
Best,
Philippe.
[ July 22, 2003: Message edited by: Philippe Maquet ]

[Andrew Monkhouse]

Just a quick note to defend my concept of extending IOException for a DeadLockException. Take a look at java.nio.channels.FileLockInterruptionException which also extends IOException:

Checked exception received by a thread when another thread interrupts it while it is waiting to acquire a file lock.

My suggestion is in the same spirit.
True deadlock is not IO in so far as it is not something physical on the disk. But do the users care? For them it is just "I asked for something, and you cannot give it to me".
I don't agree with Philippe that we can throw a RuntimeException here. If someone writing a client application does not notice the fact that we throw a RuntimeException then their code may crash in what should be a recoverable situation. (How many people do you know who use compiler errors to determine what they are allowed to do? I know a few: "It didn't complain about any uncaught exceptions, so it must be OK").
Although in defence of the RuntimeException, it does fit in with Jim's stated philosophies of not pandering to lazy coders and of making errors very obvious.

Hey guys, I just found the best way to quickly make 1..2..3..4..5..6 new friends !

That is what is so nice about JavaRanch: the fact that we can have different opinions and not be afraid to speak about them.
Regards, Andrew

[Damian Ryan]

The best way of dealing with deadlocks is to specifically exclude the possibility of their ever arising.
A deadlock can only occur if an entity (client or the server itself) can hold a lock on more than one record at a time (I'll come to the special case of locking the whole database in a moment). If multiple locks can be held, it is possible for entity one to lock record A and require a lock on record B to proceed, while entity two holds a lock on record B and needs the lock on record A to proceed.
A simple solution? Enforce the assumption that an entity (a client, for example) may only hold a single lock at a time. This is not too limiting an assumption for the scope of the exam. Ask yourself why you would ever need to get into the situation of needing locks on more than one record at a time? I think it should be possible to turn in solutions to any of the exams (FBN or new versions) that do not require such over-complicated behaviour.
On the question of locking the whole database... well, the FBN assignment I did said such an option had to be provided, so I did, but I never needed to use it. You just have to be careful that if a client asks for a lock on the whole database (using record number -1, for instance) that this request blocks while any single records are locked by other clients. This might take quite a while if there are lots of other clients making bookings. But as I said, I can't think of any legitimate reason to lock every record in the database anyway.

[Max Habibi]

Originally posted by Damian Ryan:
The best way of dealing with deadlocks is to specifically exclude the possibility of their ever arising.

Seconded.
M

[Philippe Maquet]

Hi Andrew,

Just a quick note to defend my concept of extending IOException for a DeadLockException. Take a look at java.nio.channels.FileLockInterruptionException which also extends IOException:
quote:
--------------------------------------------------------------------------------
Checked exception received by a thread when another thread interrupts it while it is waiting to acquire a file lock.
--------------------------------------------------------------------------------
My suggestion is in the same spirit.
True deadlock is not IO in so far as it is not something physical on the disk. But do the users care? For them it is just "I asked for something, and you cannot give it to me".

Good point ! You just convinced me.
Cheers,
Phil.

[Max Habibi]

Originally posted by Andrew Monkhouse:
Just a quick note to defend my concept of extending IOException for a DeadLockException. Take a look at java.nio.channels.FileLockInterruptionException which also extends IOException:

Just a quick note to defend my concept of extending IOException for a DeadLockException. Take a look at java.nio.channels.FileLockInterruptionException which also extends IOException:
Regards, Andrew

There's a big difference here: the FileLockInterruptionException is designed to be used when there's a locking exception caused by io. That's why it extends IOException. The one you're talking about has nothing to do with IO. It's a logical problem. By throwing an IOException, you're sending the Junior Programmer(poor guy) on a wild goose chase.
Remember, Exceptions are information about problems that progammers care about they're not for the GUI users, so it's irrelevant that a GUI users cares or doesn't care about hem. They're clues that you leave behind for future generations of Junior Programmers. They need to be accurate.
When I see a FileLockInterruptionException, I know that there was a problem with a FileLock Object(http://java.sun.com/j2se/1.4.2/docs/api/java/nio/channels/FileLock.html). I know, furthermore, that it's an IO problem. IMO, that's pretty useful. However, if I were to see an IOException that had nothing to do with IO, it's would be worse then confusing, it would be misleading.
JMO,
M

[Max Habibi]

Max
The professional grade solution here would be to add a data.checkLock method that returns the state of the lock. However, that might be overkill.

Overkill ?! It's a minimum, isn't it ? And even if you do, responsibility is still scattered.

The professional grade solution HERE would be to add a data.checkLock method that returns the state of the lock. However, that might be overkill. (implicit here)

M
[ July 24, 2003: Message edited by: Max Habibi ]
[ July 24, 2003: Message edited by: Max Habibi ]

[Mark Spritzler]

Hey guys, I just found the best way to quickly make 1..2..3..4..5..6 new friends !

Mark