cody koeninger <c...@koeninger.org> writes: > On Dec 6, 9:16 pm, Alex Boisvert <alex.boisv...@gmail.com> wrote: >> Lift's mapper doesn't change the default isolation level of your >> connections, nor does it make explicit use of pessimistic concurrency >> control. >> Anything beyond that we can probably implement, we just need a good >> reason... >> >> alex > > > Isn't the possibility of interleaved HTTP requests a sufficient > reason? E.g. administrator editing a field near the same time a > customer is. Unless the orm is writing everything it reads, even > changing transaction isolation to serializable won't prevent certain > types of race conditions. > > It seems like having the option to lock an entity when loading it from > the database (implemented as select ... for update) would be useful. > I haven't used Rails much, but that's my understanding of what > ActiveRecord offers.
Personally, I think using select for update is a bad idea when dealing with a UI. DB transactions should be as short as possible. On some databases, a locked record inhibits any reads (depending on isolation level of course) so the next user that comes in to view the record will just hang until the transaction times out. And what happens when the editing user just closes the browser? The record will not be unlocked until the session times out.... A much better solution imo is to use optimistic locking. /Jeppe -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
