In a multi-threaded approach all threads are c-operative since they
belong to the same process, and therefore synchronization is possible in
multiple fashions. Synchronization of multiple processes is only
possible if they co-operate, such as using file locks or semaphores.
Synchronization over a network is more of a problem, handled by "lock
managers" or daemons using inter-process communication.
I would suggest that people who want to distribute a database over a
network use a network database like PostgreSQL, not a library like
Sqlite which is crafted to be embedded into applications. As Dr Hipp
pointed out, it is a replacement for fopen(), not Oracle or DB2.
Doug Nebeker wrote:
The problem with that solution is that it assumes all database access
happens from within a single process. As far as I understand it, SQLite
allows database access from multiple processes (and even from remote
processes I assume) and thus the locking has to happen outside of the
process. In process locking would be a nice conditionally compiled
optimization, but you'd have to guarantee that no other process would
never touch the database.
-----Original Message-----
From: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 03, 2006 8:14 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Multithreading. Again.
Joe Wilson wrote:
Remember, that the operating system bug that is causing all the
multithreading grief is that file locks created by one thread cannot
be reliably removed or modified by a different thread.
You could have a single thread that exclusively performs file
locking/unlocking.
This thread would wait on a threadsafe work queue (using a POSIX
condition variable mechanism) and execute file locking/unlocking
tasks, otherwise it would use zero CPU. Functions could be provided to
put file lock/unlock operations on to this work queue and wait for the
result.
Such file locking/unlocking functions could be called safely and
reliably from any thread.
That sounds like good practice to me. When one discovers that a
particular function is flaky and variable between implementations, O/S's
and versions prudence requires that it be bypassed. In our Sqlite usage
we want platform independence and reliability and accordingly never rely
on file locking for synchronization.
A bonus of such an approach is simpler code and logic and better
execution efficiency.
JS
To find out more about Reuters visit www.about.reuters.com
Any views expressed in this message are those of the individual sender, except
where the sender specifically states them to be the views of Reuters Ltd.
