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. 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 -- Guillaume FOUGNIES
