Re: RE: Dealing with locking in bulk update scenario
- From: Niall Litchfield <niall.litchfield@xxxxxxxxx>
- To: passionate_programmer@xxxxxxxxxxx
- Date: Tue, 2 Nov 2010 16:46:38 +0000
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@xxxxxxxxxxx> 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@xxxxxxxxxxx
To: oracle-l@xxxxxxxxxxxxx
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 ...
Other related posts:
- » Re: RE: Dealing with locking in bulk update scenario - Niall Litchfield
