Example,

There is 1 oracle server.
On the oracle server, there is 1 table:

TblPrice
ID Item Price
===========
1 A 10
2 B 20
3 C 30


And there are 2 oracle clients that are logging in by 2 admin users, admin1 & admin2. These 2 users are trying to update the same table and the same row.

Admin1 is going to increase Price of Item C: old vlaue=30; new value=50
Admin2 is going to increase Price of Item C: old vlaue=30; new value=40

During Admin1 is updating, row of Item C is locked.
After Admin1 updated & commit, row of Item C is unlocked.

But on the screen of Admin2, the Price of Item C is still old value 30. Not yet refresh. Admin2 could update Price of Item C from 30 to 40. Is it logic?

I think Admin2 should be locked until he refreshs the new value 50 by Admin1 first. then he could update the Price of Item C from 50 to 40.

Plz give me your idea!!!

I don't think this is possible mate. As we can't lock admin2 while he is fetching the value b'coz at that time table is available.

I think you are right. When admin2 refreshes after that it is able to update table.
And price of the item will be changed.

This is the result of the transaction isolation.
The update is done in a session, into a transaction.
The moment the update is done is not the same the commit is done into the db.

So, the same client can see the updated value right after, because that it uses the same session than on the update, even before the update is commited to disk.

See the session like a sheet of paper, where you write things to do before putting them in your agenda. Peoples looking at the agenda won't see what you have noted on the sheet, but you have wrote it.
It's just not available to everyone who can access your agenda...

As the second client is into another session, and the transaction has not been commited to disk, it doesn't see the modification.

As saurabhj said, locking every client until each transaction is commited would introduce too much wait time.
You have to design your application with that in mind.

Two things.

It would be nearly impossible to prevent an update unless a client had run a select since the last time a row changed. Especially with bulk updates.

That's not the database's job. It has very specialized work to do, and is very good at it. What you're describing is a known issue that's possible with all databases, and is the job of the application making use of the database. Think of the other extreme - MS Access is a database, but it also does the GUI work and VBA programming. It's not good at any of its jobs. Oracle is a database engine only, and among (if not) the world's best.

It's why audit trails are used. so you can see who did what and when.

Great answers! Thanks for understanding me!

I hope all databases could prevent this issue as CVS did.