Hi all,
I was following the Rails book, and was reading about optimistic
locking. Maybe I don''t understand the concept fully, but it seems like
I
can use it everywhere, to keep my db records safe. My question is, when
should I avoid using optimistic locking? And, would this add a
significant performance hit to my webapp?
TIA,
Vamsee.
On 28.8.2005, at 12.14, Vamsee Kanakala wrote:> Hi all, > > I was following the Rails book, and was reading about > optimistic locking. Maybe I don''t understand the concept fully, but > it seems like I can use it everywhere, to keep my db records safe.Yes, as long as you take care that your app handles the exceptions optimistic locking throws you.> My question is, when should I avoid using optimistic locking?When your model is very update-heavy. That is, when it is more probable than not that two updates will collide. Note that this is very rare in normal web apps.> And, would this add a significant performance hit to my webapp?Optimistic locking is not locking at all in the strict sense, so it will not affect the read performance. It has a very slight effect in write performance for the models that use it, but if you care at all about your data, you just have to use some kind of "locking" in a multi-user environment. Optimistic locking is probably the best (and easiest) bet for you most times. //jarkko> > TIA, > Vamsee. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Jarkko Laine http://jlaine.net http://odesign.fi _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Hi all,
I was following the Rails book, and was reading about optimistic
locking. Maybe I don''t understand the concept fully, but it seems like
I
can use it everywhere, to keep my db records safe. My question is, when
should I avoid using optimistic locking? And, would this add a
significant performance hit to my webapp?
TIA,
Vamsee.
IMHO I really think of optimistic locking as a performance tuning choice that should come later on when you''re tuning. First I''d look into using transactions, and if you discover that you''re hitting a performance bottleneck, then perhaps look at converting some of the simpler updates to being optimistic updates. Jarkko Laine wrote:> > On 28.8.2005, at 12.14, Vamsee Kanakala wrote: > >> Hi all, >> >> I was following the Rails book, and was reading about optimistic >> locking. Maybe I don''t understand the concept fully, but it seems like >> I can use it everywhere, to keep my db records safe. > > > Yes, as long as you take care that your app handles the exceptions > optimistic locking throws you. > >> My question is, when should I avoid using optimistic locking? > > > When your model is very update-heavy. That is, when it is more probable > than not that two updates will collide. Note that this is very rare in > normal web apps. > >> And, would this add a significant performance hit to my webapp? > > > Optimistic locking is not locking at all in the strict sense, so it will > not affect the read performance. It has a very slight effect in write > performance for the models that use it, but if you care at all about > your data, you just have to use some kind of "locking" in a multi-user > environment. Optimistic locking is probably the best (and easiest) bet > for you most times. > > //jarkko > >> >> TIA, >> Vamsee. >> _______________________________________________ >> Rails mailing list >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> <mailto:Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org> >> http://lists.rubyonrails.org/mailman/listinfo/rails >> > > -- > > Jarkko Laine > > http://jlaine.net > > http://odesign.fi > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
On Wednesday 31 August 2005 04:48, San wrote:> IMHO I really think of optimistic locking as a performance tuning > choice that should come later on when you''re tuning. First I''d look > into using transactions, and if you discover that you''re hitting a > performance bottleneck, then perhaps look at converting some of the > simpler updates to being optimistic updates.I don''t agree on optimistic locking being about performance. First and foremost, optimistic locking is an alternative to long-running transactions with pessimistic (real) locking. The very real problem with the latter is that people might start such a transaction, leave for lunch, and render the involved objects unchangeable by others. Or consider the case where a user has started a transaction and their client application crashes before committing/aborting it. In these scenarios, optimistic locking trades the possibility of detectable update conflicts against the almost certainty of objects held captive by inactive transactions. When it comes to actually writing changed data to the database, optimistic locking has to be pessimistic too. This final writing process has to be bracketed by a transaction to ensure that consistent data is stored. Michael -- Michael Schuerig They tell you that the darkness mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org Is a blessing in disguise http://www.schuerig.de/michael/ --Janis Ian, From Me To You
Michael Schuerig wrote:> On Wednesday 31 August 2005 04:48, San wrote: > >>IMHO I really think of optimistic locking as a performance tuning >>choice that should come later on when you''re tuning. First I''d look >>into using transactions, and if you discover that you''re hitting a >>performance bottleneck, then perhaps look at converting some of the >>simpler updates to being optimistic updates. > > I don''t agree on optimistic locking being about performance. First and > foremost, optimistic locking is an alternative to long-running > transactions with pessimistic (real) locking. The very real problem > with the latter is that people might start such a transaction, leave > for lunch, and render the involved objects unchangeable by others. Or > consider the case where a user has started a transaction and their > client application crashes before committing/aborting it. > > In these scenarios, optimistic locking trades the possibility of > detectable update conflicts against the almost certainty of objects > held captive by inactive transactions. > > When it comes to actually writing changed data to the database, > optimistic locking has to be pessimistic too. This final writing > process has to be bracketed by a transaction to ensure that consistent > data is stored.Michael is right, and I''d like to add a further point: in web applications, the reading of an object from the database and the writing of the changed object back to the database take place on separate round trips to the server. To have a database transaction spanning both round trips would require tying a database connection to the user''s session (because a database transaction takes place in the context of an active connection). In general this is not possible (e.g. with CGI or FCGI), and even if it was possible it would be a very bad idea. So applications are *forced* to work optimistically, and you need to use optimistic locking whenever there is a chance of multiple users trying to update the same record concurrently. I''m impressed that Michael has build optimistic locking into his Boilerplate framework, including flagging conflicts to the user for resolution. regards Justin
Thanks Jarkko, Michael, San & Justin. That has been very illuminating. This list rocks! Regards, Vamsee.
On Thursday 01 September 2005 14:16, Justin Forder wrote:> I''m impressed that Michael has build optimistic locking into his > Boilerplate framework, including flagging conflicts to the user for > resolution.The optimistic locking is actually handled by ActiveRecord out of the box. Thanks to DHH. What I''ve added on top is figuring out exactly where the conflict is, if any, and displaying that to the user. Michael -- Michael Schuerig All good people read good books mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org Now your conscience is clear http://www.schuerig.de/michael/ --Tanita Tikaram, Twist In My Sobriety
Michael Schuerig wrote:> The optimistic locking is actually handled by ActiveRecord out of the > box. Thanks to DHH. What I''ve added on top is figuring out exactly > where the conflict is, if any, and displaying that to the user.Would it be relatively straightforward to backport this functionality into a non-Boilerplate app? Maybe even back as a patch for Rails itself? Seems like it would be useful! ~Dave -- Dave Silvester Rent-A-Monkey Website Development Web: http://www.rentamonkey.com/
On Friday 02 September 2005 14:12, Dave Silvester wrote:> Michael Schuerig wrote: > > The optimistic locking is actually handled by ActiveRecord out of > > the box. Thanks to DHH. What I''ve added on top is figuring out > > exactly where the conflict is, if any, and displaying that to the > > user. > > Would it be relatively straightforward to backport this functionality > into a non-Boilerplate app? Maybe even back as a patch for Rails > itself?Yes, I think it would be possible. In my current version, I have moved the model-related code into a mixin module for AR::Base. It adds a method update_optimistically and conflicts are attached to the model object in a way similar to errors. I.e., they can be accessed by my_model_object.conflicts. That''s only half of what''s involved, though. You still need some way to display the conflicts to the user. The "widgets" I have in BoilerPlate take care of this. Thinking of it, I''ll refactor my code to use a "conflicts_for" method along the lines of error_messages_for. The extraction of conflict handling from BoilerPlate I probably won''t do myself. At least not as long as I don''t need it. The code is still undergoing considerable changes, but once it is settled, I''ll happily clean up any dependencies that would make the extraction harder than it needs to be. Michael -- Michael Schuerig Face reality and stare it down mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org --Jethro Tull, Silver River Turning http://www.schuerig.de/michael/