Christian Smith wrote:
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
My understanding of Sqlite is that transactions are locked by locking
the entire database. Deadlocks can occur and the programmer must be
aware of the possibility of a transaction temporarily failing due to a
lock and of the need to possibly resolve deadlocks if the application
makes them possible. This behaviour is a feature of the absence of a
central DBMS server process. Sqlite runs in each user process, a major
reason for its simplicity and wide appeal.
By "enterprise" I meant the usual IT definition, a step up from
"department".
If you are interested in the complexity of MVCC take a look at the
source of PostgreSQL.
One other point, and not a hostile one, is the conception of a lock.
You seem a little confused between internal synchronisation and locks
set by the DBMS for the benefit of applications.
