[EMAIL PROTECTED] wrote:
"Rob Richardson" <[EMAIL PROTECTED]> wrote:
I found the spot where I was telling the two threads to use the same
database pointer instead of running on separate ones. Once I fixed
that, it works.
It has been suggested that I add a mutex to every SQLite
database connection. This would cause access to a database
connection to automatically serialize even when two or more
threads try to use that connection at once, thus preventing
problems such as the above.
The downside is the (minimal) additional overhead of acquiring
and releasing a mutex on each API call. There will also be
some changes to the OS-layer backend which will break
private ports to unusual OSes.
Thoughts?
--
D. Richard Hipp <[EMAIL PROTECTED]>
I would regard that as detrimental for a library which is LITE and
better left up to the application designer. However a set of
synchronizing API calls using a mutex or similar could be a nice
addition and remove what is a persistent, nagging issue for many users,
serialization from their own code.
A set of layered API calls with inbuilt access arbitration which using
Sqlite look like access to a server would be intuitive to many potential
users.
If the mutex path were taken then the file locks could be removed
entirely, with the benefit of decoupling Sqlite from file locking
implementation woes and possible performance improvements but at the
cost of implementing some form of lock manager for remote file systems
and breaking backwards compatibility.
