locking [message #385766] |
Tue, 10 February 2009 23:49  |
ramesh55.sse
Messages: 262 Registered: December 2008 Location: Hyderabad
|
Senior Member |
|
|
A table contains data like this
eno ename
1 ramesh
2 rajesh
3 ram
client A
SQL> Lock tble emp in exclusive mode;
client A performs
update emp set ename='kiran' where ename='ramesh';
client A didn't commit
select * from emp;
in that case client A gets the data like this
eno ename
1 kiran
2 rajesh
3 ram
client B performs
select * from emp;
In that case client B gets the data like this
eno ename
1 ramesh
2 rajesh
3 ram
In that case client B didn't see the changes made by client A, there is no data consistancy but what is the advantage of locking;
|
|
|
|
|
Re: locking [message #385797 is a reply to message #385766] |
Wed, 11 February 2009 01:34  |
flyboy
Messages: 1903 Registered: November 2006
|
Senior Member |
|
|
ramesh55.sse wrote on Wed, 11 February 2009 06:49 | In that case client B didn't see the changes made by client A, there is no data consistancy but what is the advantage of locking;
|
User B is unable to make any changes in EMP until user A commits its changes.
What if user A would make a change after user B reads it, but before user B would plan to make any changes on this (which is not a good approach in multiuser environment - it shall be solved differently)?
From another point of view, this is a prove of read consistency. Just imagine that user A would want to issue this: update emp set ename='ram' where eno=1;
update emp set ename='ramesh' where eno=3;
If user B would query between those UPDATEs in the way you think, he would get this: eno ename
1 ram
2 rajesh
3 ram Would you call it consistent result? Me not.
Anyway, what problem are you really trying to solve?
|
|
|