> I cite from http://sqlite.org/faq.html#q6: > > "The restriction on moving database connections across threads was > relaxed somewhat in version 3.3.1. 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 > have been finalized."
I can't say why this was written and what does that mean. But I had an application that moved all SQLite handles across threads and did that with open transactions too. And it had no problems. IIRC, there were examples of such behavior on this list too, also no problems were reported. So maybe this is really old stuff. Pavel On Thu, Feb 3, 2011 at 1:59 PM, Ulrich Telle <ulrich.te...@gmx.de> wrote: > Am 03.02.2011 15:53, schrieb Pavel Ivanov: >> It seems that this explanation as well as all other statements in the >> thread you linked are coming from the wrong assumption that SQLite's >> handles cannot be used from any thread other than the one created that >> handle. > > The explanation I gave to Stefano is *not* based on the assumption that > SQlite handles can't be passed from one thread to another. But certainly > passing them around *can* lead to problems. > >> Although this was true in some earlier versions of SQLite it's >> not true in the current version. So if SQLite is compiled with >> THREADSAFE=1 (as mentioned in that thread) then you can do with it >> whatever you want. Just beware of possible data races and potentially >> uncommitted transactions because of some open statement handles. And >> if as you say there's no simultaneous access to the database from >> different threads then there's no difference in your usage pattern >> from single-threaded one. > > I cite from http://sqlite.org/faq.html#q6: > > "The restriction on moving database connections across threads was > relaxed somewhat in version 3.3.1. 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 > have been finalized." > > The problem is that Stefano wants to pass a result set from one thread > to another. The result set has an associated SQLite statement handle > which is inherently *not* finalized. And that might cause trouble. > > If access to the database handle is serialized as Stefano claims passing > the statement handle between threads shouldn't cause problems, true, but > in that case I don't see the advantages of having a separate thread over > using a global database access instance. > > Regards, > > Ulrich > > _______________________________________________ > 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
