• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

[NX Contractor] DeadLock is a "required" requirement

 
George Fung
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I have asked if deadlock prevention and recovery should be done. The answer is "yes". I have some questions about locking.
1. If a client require to lock same clients, my program will give not throw securityException and send old lockCookie to client. any comment?
2. How to prevent dealock? it's seems very difficult.. any idea?
3. In deadlock recovery. I have an idea.
a)The server creates a locking checking thread that schedulely check if any lock timeouts. It will unlock timout locks and save the number of timeout records into a class varible(ArrayList deadLock).
b) If any thread is woke up, it will check variable deadLock. If the thread is woke up by system locking thread, it will throw DeadLockException to indiciate deadlock.
What do you think?? any new idea??
George
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have asked if deadlock prevention and recovery should be done. The answer is "yes".
Ummm, not exactly. Certainly we need to prevent deadlocks in our application as written. But that's mostly trivial - the GUI doesn't require any operations that require more than one record to be locked at a time, and we can always unlock almost immediately after the lock. (Except if a dicsonnect occurs during the booking operation.) So on one level, deadlock prevention is required, and pretty easy.
However the question then is - should the server code have more elaborate deadlock prevention mechanisnms to protect against future enhancements to client code which would require more locks to be held open simultaneously? The answer to this was "maybe". Max pointed out that he knew of people who had not done this, and gotten good scores, and he also knew of people who had done this, but their implementation was overly complex and/or buggy, and they had lost points for it. So: (a) don't assume this is a requirement, and (b) if you do it, make sure it's reasonably simple, and that it works. Correctly.
1. If a client require to lock same clients, my program will give not throw securityException and send old lockCookie to client. any comment?
Sorry, I can't tell what this means. "If a client require to lock same clients"?
2. How to prevent dealock? it's seems very difficult.. any idea?
My own preference is to require clients to acquire their locks in a particular order. (E.g. by order of recNo) If they attempt locking out of order, throw an exception.
3. In deadlock recovery. I have an idea.
a)The server creates a locking checking thread that schedulely check if any lock timeouts. It will unlock timout locks and save the number of timeout records into a class varible(ArrayList deadLock).b) If any thread is woke up, it will check variable deadLock. If the thread is woke up by system locking thread, it will throw DeadLockException to indiciate deadlock.

Well, that seems to allow the thread that was waiting to eventualy recover, after timeout. What if a user locks a record and then leaves, e.g. to lunch? The user doesn't have any threads that are currently waiting for anything; there's nothing to wake up. You can time out his lock after he's been gone too long, OK. But when he eventually returns and tries to edit the record he locked - what happens? I guess he gets a SecruityException because he no longer holds a lock on the record. It's a bit unfortunate though - the client didn't receive any notification that the lock was timed out, until a subsequent update() or other action is attempted. I suppose that's OK, but it would be nice if there were a way to warn the client before the timeout occurs. A message box saying "hey, you've been inactive too long; press OK within 60 seconds or you will be disconnected" - that might be nice. Then when timeout occurs, unlock everythign held by the client, and drop the RMI connection as well.
Just thinking of possibilities. Again, adding timeouts does make things more complex, and you don't really need to do it. So think carefully before you submit an assignment with timeouts or elaborate deadlock prevention.
 
George Fung
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1. e.g. There are other methods in DB interface. eg delete, create. The GUI can't let user to delete or create record. Why should we impelement it? I think the program should do basic function which are for later enhancement. Deadlock is common problem in DB.
2. Let me explain again. If the client program send the lock requrest twice on the same record, server will send old lockcookie for 2nd requrest.
I would like to ask if anyonce can get full marks in locking without implmentating on deadlock?
George
 
George Fung
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
anyone has idea?
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Max is busy elsewhere right now, but he has said in the past that he's had students who did not implement dealock prevention, and did not lose points for this. I don't know any more details.
 
George Fung
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks ur info
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic