Ken, Thanks for the suggestion. I'm currently doing what you suggested in that each thread has its own connection. I was wondering if I would see any kind of performance gain by using one connection instead of N. My guess is I would see a bit of a boost, but it seems like a rather large effort and may not be worth it in the end.
Thanks for the reply. On Mon, Jan 5, 2009 at 11:10 AM, Ken <kennethinbox-sql...@yahoo.com> wrote: > SB, > > You could compile sqlite without the thread safety. > > Then roll your own locking mechanism. Only one thread at a time can be > accessing the database connection/Statements. And it would be a good idea to > have whichever thread complete its transaction/work prior to release control > to another thread. > > The big problem with allowing a thread to create a transaction is in error > handling. Especially for frequently spawned threads. Say you create a mutex > to protect the database connection. The thread locks the mutex, then starts > using the database. It then encounters an error, where the thread ends. > > You'll need to keep some type of monitoring thread active to release the > database work (either reset/finalize then commit/rollback ) and unlock the > mutex. > > All of that is pretty ugly error handling code. > > I think it would be simpler to compile sqlite with thread safety enabled. > Create a connection in each thread, then access the database using sqlite > locking mechanism. Say you have an error in one thread where a > transaction was started. The next thread that creates a connection will > perform error recovery on the database. And you process/app would continue > normally. > > > HTH > > > > > --- On Mon, 1/5/09, S B <sbmail...@gmail.com> wrote: > > > From: S B <sbmail...@gmail.com> > > Subject: [sqlite] sqlite and threads > > To: sqlite-users@sqlite.org > > Date: Monday, January 5, 2009, 8:54 AM > > Hello, > > > > From: http://www.sqlite.org/faq.html#q6 > > > > "The restriction on moving database connections across > > threads was relaxed > > somewhat in version 3.3.1 > > <http://www.sqlite.org/releaselog/3_3_1.html>. > > With that and subsequent versions, it is safe to move a > > connection handle > > across threads as long as the connection is not holding any > > fcntl() locks. > > You can safely assume that no locks are being held if no > > transaction is > > pending and all statements > > <http://www.sqlite.org/c3ref/stmt.html> have been > > finalized > > <http://www.sqlite.org/c3ref/finalize.html>." > > > > In an application which spawns worker threads to issue some > > queries and has > > some other standalone threads that run for the lifetime of > > the application, > > what is the best way to manage a single sqlite3* > > connection? Any of the > > threads could issue queries and begin/commit transactions > > against the > > database. I'd also like to use prepared statements > > with this connection as > > well so all threads may use them. > > > > Is this feasible? > > > > Thanks and Happy New Year, > > > > SB > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@sqlite.org > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
