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+unsubscr...@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.
