> You're confusing threads with the context of the connection. When you > call sqlite3_open() you get a single connection to a db. That > connection can then be used across threads, but it is for all intents > and purposes a single line of communication with a database (using it > twice at the same time doesn't somehow multiply that relationship).
Thank you for attempting to clarify this for me. You are saying that the transaction state is part of the connection context, whereas I was expecting it to be a per-thread-per-connection state. I had thought, based on the documentation, that there was little or no functional difference between: A) Two threads, each of which has its own database connection B) Two threads, sharing a single database connection Note that your example of two threads attempting to update the same record at the same time is consistent with this theory -- in either case SQLITE_BUSY (or similar) is likely to occur on one of the threads. In my case, I was also expecting to get SQLITE_BUSY (or similar) with the second transaction, rather than an error. (I'm well aquainted with the SQLITE_BUSY behavior and application-level synchronization techniques.) What else, besides transaction state, is part of the connection context and shared with shared connections? I know of the page cache, of which sharing is desired. Anything else to be aware of? ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
