----- Forwarded by Ben Carlyle/AU/IRSA/Rail on 27/02/2004 09:53 AM -----
Ben Carlyle
27/02/2004 09:49 AM
To: [EMAIL PROTECTED]@CORP
cc:
Subject: Re: [sqlite] multithreading
Dave,
[EMAIL PROTECTED]
26/02/2004 04:56 PM
To: [EMAIL PROTECTED]
cc:
Subject: [sqlite] multithreading
> Since I'm
> debugging, I'm crashing a lot before I have a chance to sqlite_close()
> the database. Is that the problem? If it is, is there any way to
> unwedge a database if the app crashes before closing it?
sqlite uses operating-system locks. When your process terminates, the
operating system will remove all locks that process owned. I presume from
the fact you can delete the file while it's still locked (and therefore
open) that you're running a unix variant? I would be checking the output
of lsof to see exactly which process still had the file open.
> I'm trying to access the database from two threads: the UI thread
> mostly reads and occasionally updates rows, while the network thread
> loads new messages and inserts them. Will that work, or do I just
> misunderstand how SQLite does multithreading?
It is important that each thread has its own sqlite*, each coming from a
separate sqlite_open call. If that condition is met, nothing should
actually misbehave. Be warned, though, that each thread will lock out all
other threads while it is querying or modifying the database. If any
thread locks the database for too long, the other threads attempting to
access the database will have SQLITE_BUSY returned. It is possible to hack
blocking locks into sqlite to make the waiting thread sleep, instead, but
I'll leave that as an exercise for the reader (or drh).
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
