Deadlock and wait(long)

[Tony Collins]

Reading the thread about deadlock management has been very benifical and I believe that it does feel right to track the locks in the data class.
My question is a hypothetical one. If the interface specified by SUN allowed us to implement a solution using a weak hash map in Data, could we avoid the problem of a thread being locked out by using wait(timeout) instead of wait() ?
Tony

[Andrew Monkhouse]

Hi Tony
Yes, you could probably use a timed wait. This would be inside a while loop (of course) so if the timer expired, then you would go back and check whether the lock had been released.
Another option might be to counter in your Data file that you increment every time you gain a lock, and decrement whenever you remove a lock. Then just create a thread that compares the number of locks that your counter says should be in the WeakHashMap with the number of locks really in there, and if they differ, then do a notifyAll().
Both might fall foul of the following requirement though:

// If the specified record is already locked by a different
// client, the current thread gives up the CPU and consumes no CPU cycles until
// the record is unlocked.

Regards, Andrew

[Max Habibi]

Originally posted by Tony Collins:
Reading the thread about deadlock management has been very benifical and I believe that it does feel right to track the locks in the data class.
My question is a hypothetical one. If the interface specified by SUN allowed us to implement a solution using a weak hash map in Data, could we avoid the problem of a thread being locked out by using wait(timeout) instead of wait() ?
Tony

Hi Tony,
A couple of points.
1. I believe, based on my conversations with the folks at Sun, that the only deadlocking issues we need to deal with are logical ones, arising from the threading strategy in lock/unlock. We don't have to deal with exceptional situations, like a client dying. That's not to say we shouldn't in every case, but we don't have to. I know Kathy a bit(we might be working on a book together later this year), and I'm pretty sure that she says what she means. That is, there's a reason why both my book and hers advocate that you not go beyond the requirements.
2. The WeakHashmap falls perfectly in with the Data class currently, as with your suggested solution. here's one simple implementation. Data has two maps: a static weakhashman called, say, allLocks, and an instance map(say a TreeMap) called myLocks. When you need to lock/unlock a record, you synchronize on allLocks, insert the Integer {(recno),Long(cookie)} into it, and also insert {(recno),Long(cookie)} into myLocks.
2. That's it. No Unreferenced, controlling how many times it's called, etc.
3. The Thread.wait suggestion seems a little suspect to me, because, in concept, this isn't really different then the old programmers trick of looping to 1000 before going on. A client could have a legitimate reason for holding onto the lock for longer then whatever arbitrary timeout you set, and timing out prematurely might lead to more problems then it solves. It's probably better to let the system deal timeout, etc based on the JVm. Then it's not your code, it's the nature of the larger system that's deciding when locks are released.
All best,
M
[ July 15, 2003: Message edited by: Max Habibi ]

[Tony Collins]

Cheers I think I see ?
So if a client goes down the data class will be garbage collected. myLocks will be gc'd and then the reference will be deleted from the weak hashmap.
So this solution would require an instance of Data for each client.
Excuse me if I'm not fully up to speed I'm a bit new to JAVA and this project. Should really stick to the basics but it's interesting.
Thanks alot
Tony

[Max Habibi]

Originally posted by Tony Collins:
[QB]Cheers I think I see ?
So if a client goes down the data class will be garbage collected. myLocks will be gc'd and then the reference will be deleted from the weak hashmap.

Exactly!
IMO, it falls elegantly into place. You need to keep track of all of the locks, and you need to keep track of individual locks. Thus, you need these two maps somewhere. Why not have them in you db avatar( namely, Data). It follows directly then, since you need a map anyway, why not a WeakHashmap, and get connection-loss recovery mechanism for free?

So this solution would require an instance of Data for each client.

I prefer to think that it allows an instance of Data for each client, as opposed to forcing all of the client to share a single Data instance

Excuse me if I'm not fully up to speed I'm a bit new to JAVA and this project. Should really stick to the basics but it's interesting.
Thanks alot
Tony

Not at all: you're raising excellent points, and exploring your concepts thoroughly. Frankly, I doubt you're as much of neophyte as you make out
All best,
M
[ July 15, 2003: Message edited by: Max Habibi ]