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 <[email protected]> wrote: > From: S B <[email protected]> > Subject: [sqlite] sqlite and threads > To: [email protected] > 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 > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
