Problem due to read consistency...

Question

Hi,
Pls hv look on given scenario...
Two transactions updating the same row
Session 2's update waits until Session 1's commit release the row lock.
In Session 1
SQL>select color from cust where id=500;
color
red
SQL>update cust set color='blue' where id=500;
In Session 2
SQL> select color from cust where id=500;
color
red
SQL>update cust set color=green where id=500;
(Waiting...)
In Session 1
SQL> COMMIT;
In Session 2
SQL>select color from cust where id=500;
color
green
SQL>COMMIT;
Due to read consistency second user never knows that someone had changed color to 'blue'.
We can use flags etc to trap this.
Is there any way in Oracle to stop this logical inconsistency ....?

Answer 1

> I can use select ...for update for the purpose. but there r few reasons for
not using this...
We use JAVA with Oracle.
Not a valid reason. If the language is incapable, or the application server is incapable, then change it.
You cannot blame the RDBMS for not working when the problem is solely with the language/app server. And you will have the exact same problem with any RDBMS as the lock-row-before-updating is a fundamental RDBMS rule for protecting data integrity and guarding against lost updates.
> If Java program crashes then the lock not get automatically released from
Oracle.
I'm not sure that this is a valid statement. I deal with Java apps from JBoss against my databases and I've yet to see this problem.
But for the moment, let us assume you are correct - what happens when the Java app crashes after the UPDATE and before the COMMIT? The exact same problem. So how do you solve this? You cannot simply just ignore those locks and pretend that the locks created by the SELECT FOR UPDATE is a problem.
Also, why are your Java programs crashing so much? If it does not work, fix it or replace it.
> Any idea ?
You can use optimistic locking. This is not preferable. It results in a serious performance issue (and data concurrency issues) with any kind of higher volume OLTP system.
But when dealing with stateless clients (typical 3 tier architecture using web browser clients), there is no choice but to use optimistic locking. E.g.
SELECT c.* INTO :existing_row FROM cust WHERE id = :0
.. processing..
UPDATE cust
SET colour = :new_colour
WHERE custid = :0
AND cust_col1 = :existing_row.cust.col1
AND cust_col2 = :existing_row.cust.col2
AND cust_coln = :existing_row.cust.coln
In other words, the UPDATE checks that the row has not been changed since it was last "seen". If the UPDATE returns a 0 row result, it means that the row has changed. In which case the app needs to handle that exception somehow.