On Wednesday 16 August 2006 12:55, Christian Nassau wrote: > Ulrich Schöbel wrote: > > I thought about that, but I didn't want to include > > the selects into the locked phase, keeping lock > > times as short as possible. Shouldn't it work > > correctly with a deferred lock? > > I don't think so: imagine two processes that have succesfully carried > out their selects (possible, since you've only got a shared lock at that > point) and now want to proceed to the update: > > SELECT(1) SELECT(2) > <-- process 1 here <-- process 2 here > UPDATE(1) UPDATE(2) > > At this point SQLite cannot allow UPDATE(1) because it might potentially > invalidate the result of SELECT(2) (and vice versa). So there's no sane > way through and at least one transaction is forced to error out. > > > --------------------------------------------------------------------------- >-- To unsubscribe, send email to [EMAIL PROTECTED] > --------------------------------------------------------------------------- >-- Yes, sounds plausible. It's obviously the way to go.
Thanks again Ulrich ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
