I was reading sqlite3_open documentation earlier this week and noticed that the docs say:
"The returned sqlite3* can only be used in the same thread in which it was created. It is an error to call sqlite3_open() in one thread then pass the resulting database handle off to another thread to use. This restriction is due to goofy design decisions (bugs?) in the way some threading implementations interact with file locks." http://www.sqlite.org/capi3ref.html#sqlite3_open I was surprised to see this because I was under the impression that this issue had been fixed as you mentioned below. I'm glad to hear that it really is fixed. Is this a "documentation bug" leftover from previous versions? Thanks! Pat -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, June 01, 2006 8:38 AM To: sqlite-users@sqlite.org; [EMAIL PROTECTED] Subject: Re: [sqlite] Multithreading. Again. "Peter Cunderlik" <[EMAIL PROTECTED]> wrote: > Hello everybody, > > I'd like to ask a couple of silly questions before newcomers like me > get moderated. :-) I've browsed through the documentation and this > mailing list, trying to understand issues with multithreading. I'd > like if someone could confirm my conclusions. > > 1. As of SQLite 3.3.5, there is no multithreading (MT) problem with > the SQLite itself. All problems come from the underlying OS libraries. I would argue that this has always been the case. But beginning in version 3.3.1, SQLite has taken additional steps to partially work around problems in the OS. So the OS problems are less troublesome. > > 2. The only MT problem is with locking the database in a case when a > thread uses sqlite3 structure created by a different thread. Thus, > using connection pool (allocated by one thread, used by other threads) > is not safe. This was the case prior to version 3.3.1. Beginning with 3.3.1 and following, you can move an sqlite3 structure from one thread to another as long as there are no locks being held by that structure. The easiest way to make sure that no locks are held is to finalize all statements associated with the sqlite3 structure. > > 3. Just a thought: In case of in-memory database, no file locking is > required, so MT is no issue. (?) Correct. Of course, it has always been the case and probably always will be that you cannot use the same sqlite3 connection in two or more threads at the same time. You can use different sqlite3 connections at the same time in different threads, or you can move the same sqlite3 connection across threads (subject to the constraints above) but never, never try to use the same connection simultaneously in two or more threads. Often you will get an SQLITE_MISUSE error if you try to use the same sqlite3 connection in two threads at the same time, but there are race conditions which can cause this error check to be missed, so do not count on it. -- D. Richard Hipp <[EMAIL PROTECTED]>
