Guillaume Fougnies wrote:
Wed, Sep 14, 2005 at 11:43:43PM +0200: Rolf Schaeuble wrote:
Dennis Jenkins wrote:
Rolf Schaeuble wrote:
Hello,
if I understand the whole issue correctly, there is only one reason
why it's not safe to use a sqlite handle in any thread of a process
(as long as only one thread at a time uses it): File locks are tied to
the thread that created them (except this special Redhat version).
That's why on Windows everything's safe, since file locks are
per-process there.
If that's correct, couldn't this problem be solved by letting sqlite
use a dedicated thread to do the locking? Each time a lock needed to
be set/removed, a message would be sent to that thread which then
would perform the locking. That should make it safe to use the sqlite*
from any thread.
For single threaded applications that would mean more thread
switching. For multithreaded applications, however, life wouldn't only
become easier, but performance may well increase. In my applications I
have a dedicated database access thread. Each time a query needs to be
executed, it's sent to this thread. In this case I have thread
switching anyway. Only having it when a lock is set/removed will
decrease the amount of switches.
Best regards
Rolf Schäuble
I disagree with the entire approach. It seems hackish.
Just have each thread create it's own sqlite handle. So long as one
thread does not need to "pass off" an exisiting handle to a different
thread you will be fine.
That doesn't work for me. During one single transaction several threads
need to insert data into the db; due to this transaction, all threads
have to share a single database handle.
No.
Each thread needs to open its own db handle and let SQLite make
the lock job. That's all.
Well, don't take that "share" literally. Only the dedicated thread
actually issues commands. But I can only have one single database
handle, since my scenario looks like this:
- Start (exclusive) transaction.
- Several threads produce data to be written into the database
- Commit/rollback transaction.
The database is locked during the transaction, so the threads can't open
their own handle and use that.
Since you don't need a db handle opened by thread(a) to be used
by another thread (b), you won't have any problem...
If you need to, you will need my "lost patch" :)
http://www.sqlite.org/cvstrac/tktview?tn=1417
Well, I need, but this patch doesn't help. I would get SQLITE_BUSY all
the time while the transaction is running.
In my opinion the whole problem is that threads can't override locks of
other threads. Letting a dedicated thread do the locking would kind of
allow this. Besides making the usage of sqlite easier, it would also
result in the same behaviour as on the Windows platform.
