|
|
Posted by Gordon Burditt on 09/09/05 06:02
>The problem is that many deadlocks are not actual deadlocks, there are
>also hangs and infinite waits, with the same unpleasant effect for the
>end-user. End users are rarely happier if you explain them the true
>nature of their plight, they will usually come up with an unreasonable
>request to get the [EXPLETIVE DELETED] thing done. Infinite waits happen
>when user inserts a record into our lucky database, then receives a phone
>call from a friend and goes to lunch. Application, on the other hand,
>doesn't commit until the user answers the necessary question "Are you sure
>[Y/N]:". Anybody else who wants to lock the same resource can only hope
>that their colleague had opted for the fast food joint. Usually, fast food
>is not fast enough to prevent the others from becoming somewhat unhappy.
.... and in Texas, getting out The Rope.
>The solution: don't create applications which do that. No locks of any
>kind should be imposed on the system until the user decides to perform the
>actual commit. Technically, that's not a deadlock, it's an infinite wait.
It's not really an *infinite* wait until the guy goes to lunch,
then gets hit by a bus or is fired before he gets back. It may
seem like it to everyone else in the office, and they may start
chartering busses.
>Make sure that your users are aware of that fine distinction.
That's important, because the users may need to make you aware of
the fine distinction between a hanging and a lynching, by demonstrating
on you.
However, the application may NEED locks or the equivalent in this
situation in order to preserve data integrity, or some way to
indicate a "virtual deadlock", otherwise known as "somebody edited
the record out from under you". Assuming that the process is that
the customer service rep brings up the user's account, then uses
that information plus the customer request to make changes, with
possibly a long time in between, bad things can happen to the
customer info when two reps edit the same record at the same time.
A lot of this may be computed in the rep's or the customer's brain.
Customer to Rep A: How many mailboxes do I have?
Customer's wife to Rep B: How many mailboxes do I have?
Rep A to Customer: (brings up account screen) 8
Rep B to Customer's wife: (brings up account screen) 8
Customer to Rep A: I need 9 total. Add another one.
Customer's wife to Rep B: I need 9 total. Add another one.
Rep A to Customer: (Clicks SUBMIT on update, gets result)
Ok, we've added another one.
Rep B to Customer's wife: (Clicks SUBMIT on update, gets result)
Ok, we've added another one.
.... Later ...
Customer to Rep C: How the #*&(*^#@ did I end up with 10 mailboxes?
I didn't ask for that!
One way around this (in the web environment, especially) is to hide
the old record contents in the form. After the rep hits the SUBMIT
button, the code compares the old record contents in the form with
those in the record. If they changed in a significant way (figuring
out what is significant and what isn't may be subject to debate),
reject the update, indicating that the record has been changed.
This does have a disadvantage that it's likely to reject completely
independent changes that aren't really conflicting.
Gordon L. Burditt
Navigation:
[Reply to this message]
|