Ruby on Rails Monday, March 3, 2014



On Monday, March 3, 2014 3:37:06 AM UTC, femto wrote:
Hello all,for Optimistic Locking, I believe 
the implementation is like this:
rails will issue the following statement to database
Update user set name="a",version=2 where id=1 and version=1
but the problem is, generally database will have transaction Isolation
(I believe Oracle do),
so when Thread 1 issue that statement to database but not commited,
Thread 2 will also issue that statement to database, because transaction Isolation,
thread 2 will not see this user as version 2 but still version 1(unless thread 1 commited)
(otherwise thread 2 is reading uncommitted which is not correct),
then thread 1 commit, thread 2 commit,
then all of a sudden, all threads are happy, the user record is still being modified by 
two threads, the optimistic locking doesn't work,

Is this correct?
Correct me if I'm wrong.

Don't know about oracle but for mysql to update the row you'd have to acquire a lock on it (an exclusive lock if my memory is correct) - the second thread would have to wait for the first transaction to be committed in order to be able to make its update 

Fred

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/299d9b19-f606-4eef-91a8-a577b9919c92%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

No comments:

Post a Comment