On Wed, 7 Dec 2005, John Stanton wrote:
>Christian Smith wrote:
>>>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.)
>>
>
>What could be simpler? Implementing transactional integrity by means of
>locks rather than multiple versions of data and complex housekeeping,
>particularly if the intended application doesn't depend upon MVCC for
>performance with a large number of concurrent users. Dr Hipp is very
>clear in advising not to use Sqlite for enterprise applications.
I'd guess MVCC would be simpler to implement than row locks. With row
locks, you have to track every transaction, every row accessed by every
transaction, and detect and handle any deadlock conditions, as well as
correctly lock the metadata for updates.
With MVCC, you simply have to lock the metadata briefly for inserts
(updates) or deletes, track every live transaction, have no problems with
read/write lock deadlocks, and easy to detect stale row updates. Vacuuming
adds some performance overhead, but can be externally scheduled and simply
implemented.
What would you class as enterprise? I think SQLite is very suitable for
certain classes of enterprise applications, just not as the primary data
store for a large data warehouse or some such application. As an example,
consider something like a directory service. A very 'enterprise' type of
application, and one I think SQLite would excel at.
>
>If you follow this mail list you will see that Sqlite is in some ways
>too "heavy" for some of the embedded applications where it is used.
>Options to create an "Sqfeatherlite" would be more useful than
>attempting to create yet another general purpose, full function RDBMS.
>
Err, I wasn't proposing that. I explicitly stated I thought MVCC was too
heavy weight for SQLite. I sense this thread getting hostile, which was
not the intention. I think we're simply talking at cross purposes.
Christian
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
