[EMAIL PROTECTED] schrieb:
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.
Thank you for you reply.
I just had made the fault to think it would be only exclusive to process.
but after setting it in my app, the main thread ( which is only reading)
blocked all write accesses of the update thread.
so what i have learned is that if your apllication does access a sqlite
db from more than one thread, one cannot use
the exclusive mode. i wonder if aperture does only access its db from
one thread.
regards,
gunnar
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
