This content has been marked as final. Show 3 replies
Row locking problems are not because of RAC, these are badly written codes which needs to be resolved by committing frequently. so lock waits caused by row level locking or explicit lock commands are issue of application
1 person found this helpful
oradba11 wrote:In principle this is not possible - it's either an application error or a fundamental and catastrophic Oracle bug that people would have made a huge fuss about years ago (and I don't recall hearing such a fuss).
I am wokring on oracle 10.2.0.4 rac 2 node nistances on AIX.
We have one table having multiple rows defilning jobs will be done by users ...the functionatily is that ..when even one user will pick on row (job) , one update
statement will issue and it will update status column to 1 which menas job is allocatated , this means now this should not allocate to any other user ..
but we are facing issue that once any user will pick that job , in applicatoin log files we can see that row gets lock and updates the status to 1 . but then also
users connecting to other or some time same instance will get that job...means multiple users can pick same job .. even after already picked by other user ..
Is this can be issue with rac configuration ... like when ever one user updates a row ..it will be in cache of one instance and when other user trys to again update
2nd instance does not have that information and allows user connected to that instace to pick that job..like delay in block tranfer or cache fusion..
is this can be issue with rac or it is purely application issue...
ok , so now we need to look at application level only ..
thanks for information ...