Gunnar Roth <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] schrieb: > > SQLite version 3.3.14 is now available on the SQLite website > > We have also added > > the concept of "exclusive access mode". In exclusive access > > mode, SQLite holds onto locks until you close the connection > > > I should maybe made clear that this new behaviour influences not only > per process concurrency but also thread concurrency. >
To make it really clear, when you set PRAGMA locking_mode=EXCLUSIVE; You get no concurrency at all. The one database connection that holds the lock has exclusive access and no other database connections are allowed to read or write to the database in the meantime. This is either a good thing or a bad thing, depending on your needs. Traditional RDBMS thinking is that this is a bad thing. But SQLite is not used in traditional ways and so for many uses of SQLite, locking down the database is a good thing. For example: In monotone, when syncing two to repositories (each repository is an SQLite database in monotone) they want to break the sync up into multiple transactions. But they do not want another process to slip in and modify the database during the brief instant after committing one transaction and beginning the next. They can now accomplish this by setting exclusive access mode. Programs that use SQLite as an appliation file format (ex: Adobe Lightroom) often cache active parts of the database file in internal data structures. They do not want other processes slipping in and modifying the on-disk database out from under them. By going to exclusive access mode they can prevent this. A lot of users wrap the core SQLite library into a database server. Various threads or processes have to send messages to the server and the server interacts with SQLite. In this case, there is only one connection to the database, so it makes sense to put SQLite in exclusive access mode. Related to the last point: As far as I am aware, SQLite is the *only* SQL database engine in existance that allows two or more independent processes to open and interact with the same database file at the same time. In every other SQL database engine, there is a single server process that always has exclusive access to the data and all clients must go through that server. Even other "embedded" databases such as MySQL-embedded, Firebird-embedded, and CloudScape, work by setting up a separate server thread and funnelling all disk traffic through that server thread, I am told. So to look at it another way, all other SQL database engines in the world are locked down into exclusive access mode. Only SQLite has the ability for separate databases to talk to the disk file independently of one another. The "exclusive access mode" in SQLite is just giving SQLite the ability to turn this unique feature off in cases where it is not needed. -- D. Richard Hipp <[EMAIL PROTECTED]> ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------