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] -----------------------------------------------------------------------------
