Christian Smith wrote:
On Fri, 2 Dec 2005, C C wrote:
On 12/2/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
The added risk in going from synchronous=FULL to synchronous=NORMAL
is minimal. You only run into trouble [when] you select
synchronous=OFF.
you've piqued my interest... Does sqlite implement MVCC (multiversion
concurrency)?
No.
Might be an interesting addition, but locking of the btree structure would
be difficult to make performant, as communication of locking is via file
locks only. MVCC works very well on centralised servers because locks are
short lived and can be quickly communicated using regular IPC.
It might be feasable to have intra-process MVCC on a single SQLite
database with multiple handles, but inter-process MVCC would be
problematic, as is scheduling vacuuming of stale data. It could, however,
remove the limit that a writer cannot commit until all readers are
finished, so improving concurrency somewhat.
Basically, it'd be too complex (IMHO) to implement in a 'lite' database
engine.
-cc
Christian
The virtue of MVCC is that it does not use locking, instead it maintains
serialized versions of the data. The whole point of the "lite" in
Sqlite is that it does not use those heavyweight DBMS methods which make
a DBMS capable of handling thousands of concurrent transactions.
The massive overhead of MVCC is pointless when the DBMS is in a small
scale application with at most a handful of concurrent transactions.
Sqlite's locking method is quite appropriate at that level.
JS
