On 10/26/2011 7:45 AM, Robert Porter wrote:
Accountants... How about a ER doc waiting on lab results for cardiac
enzymes? I can hear it now: "Sorry Doc, something else locked the
record. Your patient's test request was skipped so we could implement
a trivial solution that was suggested for deadly embrace. Try again,
and hope for the best that it goes through this time."
As opposed to what alternative?
Remember, the ER doc is in this situation because some process wanting
to deliver the lab results that the doc is waiting for is being blocked
by locks held by a 2nd process.
And, if it's a deadlock, that 2nd process can't proceed because the 1st
has something it needs.
So how should we respond to that scenario?
Should we let the deadlock daemon handle it?
It will kill one of the 2 processes.
Perhaps the one the doc needs.
Perhaps with data loss.
Perhaps with data inconsistencies which might be even worse for said
doc. Missing data is a Known Unknown. Lying data is an Unknown Unknown.
Should we wait for IT staff to figure it out & kill the process?
I hope they kill the right one.
Someone may be able to resubmit the transaction manually.
Or maybe IT can cobble the data.
That doesn't seem very timely if I'm the cardiac patient.
-----
When I say "trivial", I don't mean "magic" or even easy. The trivial
part is the initial analysis:
If you have deadlocks,
then you need to add appropriate LOCKED clauses.
There's a whole lotta non-trivial hours inside that word "appropriate"!
The goal is to use a LOCKED clause to prevent entering a deadlock,
then back off long enough so the other guy can complete his task, then
you proceed. Most of the time, if you do it right, the whole thing
will happen before the ER doc blinks.
Actually, that's a general approach to lock blockage beyond deadlocks.
For example, rather than camping on the readu, waiting for a lock for
Result1, it can go ahead & process Result2, allowing the ER doc to
decide treatment for patient-2.
BTW, the case of the potential deadlock is really the nicest of all
possible lock problems because the process being blocked is in control
of unblocking the process blocking him! Other situations are usually
out of the program's control, such as a user on a coffee break, or file
maintenance running late.
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
