Hello: I have an application that makes heavy use of sqlite3 and during load testing I very, very rarely (read: it has only happened once so far) occasionally see the following error message:
"BEGIN EXCLUSIVE error: cannot start a transaction within a transaction" I understand this error message and usually I cough it up to some connection issuing a "BEGIN;" statement after a previous transaction has already started and not been finalized by either a "COMMIT;" or "ROLLBACK;" statement respectively. However, if an application shares a single connection to an sqlite3 database and that connection was opened up with SQLITE3_OPEN_FULLMUTEX, (note the complete flags were "SQLITE_OPEN_CREATE|SQLITE_OPEN_READWRITE|SQLITE_OPEN_PRIVATECACHE") aren't all queries in effect serialized? And as such this error condition above can never occur between different threads holding the same connection that was opened with the full mutex flag? Specificially, if thread 1 and 2 both have a handle to sqlite3 with full mutex, then both could start a transaction simultaneously, one will win the other will wait, and life goes on. I did read this thread: http://sqlite.1065341.n5.nabble.com/Multiple-reads-and-writes-to-a-single-DB-connection-from-multiple-threads-td75972.html And based on that I believe I'm right but I want to verify my understanding of this flag. Of course, now I need to understand how the above even happened if everything above holds true (I can't find where a single thread of execution could issue "BEGIN" twice in my code though I did find that I was calling sqlite3_lastrow_insert() twice in a row by accident but I don't know how that could cause the above.). Thanks! -aps _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
