You are right, you don't always know in advance which records you need
to lock.
If the processes are human controlled this can be solved by letting each
user know who is locking whom out and they can solve the problem
hopefully themselves.
If phantom processes are doing this you don't have this
Hi,
You can avoid a deadly embrace if you can arrange it so that all processes
lock related tables/files in the same sequence.
Take the example of a system with a CUSTOMER file, a ORDER HEADER file and
an ORDER DETAILS file. If some processes lock the ORDER HEADER file first
and the CUSTOMER
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
On 26/10/11 00:23, Steve Romanow wrote:
I reread my post and meant no disrespect Wols. I shouldnt post replies
without considering twice.
No worries Steve. I shoot from the hip sometimes too - it can be
embarrassing :-)
Cheers,
Wol
___
U2-Users
I find the best practice is to try and lock and read all the necessary
components before the first update. That way if an item we need to update
as we go along is unavailable we catch it up front and don't get stuck.
Or if you have TRANSACTION PROCESSING in place you can just to an ABORT.
I
It's not possible to know every lock you may wish to set in advance David,
that's the problem.
Some locks can be set, but unknown, until the user has done something.
Like in my example where the user changing a field in one record, causes
another update to be triggered in some other record.
You
Come on, get real.
Do you suggest the deadly embrace would be better and he would get his
results any quicker?
And anyway, an ER doc not getting his lab results because of a mass
update process running as a phantom encountering a locked record?
And who would hold a lock on those lab results
I'm suggesting that blinding skipping records is a HORRIBLE idea, and in our
case, potentially life threatening - literally. You need to get real with your
suggestion that coding for deadly embrace situations is a very easy solution
(your words). Not every phantom is a mass update. The IS
What do you think I am doing day in day out?
I work with Avante 9.2 from Epicor and I definitely didn't write that
myself.
And this isn't the first system I've worked with in nearly 25 years in
the MV world.
And to be honest I have barely scratched the surface of Avante since I
only look at
Will - you couldn't be more wrong in your last paragraph. FWIW Knowing Asvin
and the systems he works on I can tell you they are anything but simple -
highly complex rules handling many hundreds of concurrent processes and
millions of transactions per day... in fact right at the other end of
I never said anything about blindly (I guess that's what you meant)
skipping records.
I suggested writing the locked record ids somewhere else and process
them later for Wills not necessarily life-threatening sales rep update
phantom.
I at least don't feel threatened by accountants.
If
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
That's not really relevant to what I said.
It's not a question at all of the *number* of transactions or processes, nor
how complex the business rules are.
It's much more relevant to the complexity of the history of the software.
That someone would suggest that locks can be set in the same
Oh, and Roadrunner is faster than Sonic ... definitely.
:-)
Sincerely,
David Laansma
IT Manager
Hubbard Supply Co.
Direct: 810-342-7143
Office: 810-234-8681
Fax: 810-234-6142
www.hubbardsupply.com
Delivering Products, Services and Innovative Solutions
-Original Message-
From:
14 matches
Mail list logo