Re: RE: Dealing with locking in bulk update scenario
Date: Tue, 2 Nov 2010 16:46:38 +0000
Message-ID: <AANLkTikyJoKsM-EuS9HKXMN2A9vKg79h-KNHdi1hydBp_at_mail.gmail.com>
Reread Stephane and Nigel's posts again. You could do worse than look at the bank account example in Tom Kytes expert one on one book as well since it is fairly analagous. The bottom line though is that at least one of your processes looks as if it is trying to reinvent transaction management and failing with 2 concurrent transactions. I'd lay bets on the batch update, but it may well be that the shop update *also* does a select and then assumes no other transaction has modified the row.
On 2 Nov 2010 15:37, "RP Khare" <passionate_programmer_at_hotmail.com> wrote:
Hi Professionals,
One possible solution that flashes my mind is to request my DBA to add a TimeStamp column and also create a trigger. The trigger's job would be to match the time-stamp before each update. If the in-memory time-stamp and the existing time-stamp mismatches, it must not update that row and log the event. Updates on such rows must be performed after this batch update job is over.
Just a view. Let me know your views.
..................
Rohit P. Khare
From: passionate_programmer_at_hotmail.com
To: oracle-l_at_freelists.org
Subject: Dealing with locking in bulk update scenario
Date: Tue, 2 Nov 2010 15:13:46 +0530
Let me clear the scenario, the real-life issue that we faced on a very large database. Our client ...
--
http://www.freelists.org/webpage/oracle-l
Received on Tue Nov 02 2010 - 11:46:38 CDT