On May 7, 2005, at 11:50 AM, Darren Duncan wrote:
However, row-level locking is something else; I see this as being too complex to implement in the 3.x series, if SQLite ever implements it; so no vote for this. In fact, the existing support to lock the whole database that 3.x supports now, which allows for multiple concurrent readers, is quite powerful on its own considering the simplicity. That said, if row-level locking is supported later, it should probably be a compile-time option, since it would slow things down for people that don't use it from the overhead.
I really think locking rows with triggers is the way to go. In fact, even if it were built into SQLite itself, I would think the implementation would be something like a trigger. To be more specific, triggers basically let you insert your own hooks right into the VM, so you are guaranteed that the execution of an UPDATE or DELETE that fails because of a locked record will unwind itself correctly.
The other cool thing about using triggers to do record locking is that there is zero overhead if there are no locks.
