On Tue, 6 Dec 2005, John Stanton wrote:
>Christian Smith wrote:
>> On Fri, 2 Dec 2005, C C wrote:
>>
>> Basically, it'd be too complex (IMHO) to implement in a 'lite' database
>> engine.
>>
>>
>The virtue of MVCC is that it does not use locking, instead it maintains
>serialized versions of the data.
The btree must still be accessed and updated in a serialized fashion to
prevent corruption. MVCC removes the need for locks on whole databases,
tables or rows. But the metadata still requires locks for updating.
It is these metadata updates that would slow down throughput that a
centralized db doesn't suffer from. The centralized db can use regular
locking primitives to coordinate metadata updates (such as mutexes and
condition variables.) SQLite does not have that option except within a
single process.
> 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.
Agreed.
>
>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.
Having never implemented a MVCC database (nor any database, for that
matter:) I couldn't authoritively comment, but MVCC doesn't strike me as
being particularly high overhead. A couple of extra hidden columns per
row, tracking transaction id's and the odd vacuum every now and then. What
could be simpler:) Certainly not massive overhead, and probably easier
than table or row level locking (think deadlocks.)
>JS
>
Christian
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
