[EMAIL PROTECTED] wrote:
Bill KING <[EMAIL PROTECTED]> wrote:
Could this be cause by one thread opening a transaction, then a second
on a second connection trying to open a transaction on it, and failing
to open the transaction file (as it already exists?).
No.
Each database connection (each sqlite3* pointer) has a boolean
field called "autoCommit". If autoCommit is false, that means
a transaction is active. If autoCommit is true, that means you
are not inside a transaction. autoCommit is true by default,
of course.
Executing BEGIN does not do anything with the disk. All it does
is change the autoCommit flag from true to false. If the flag
was already false at the time BEGIN is executed, it generates
the "cannot start a transaction within a transaction" error.
The important thing to note here is that BEGIN never does
any system calls - it never interacts with the database file
in any way. All it does is set what should be a private boolean
variable to false.
Now, if you do BEGIN EXCLUSIVE or some other variation on BEGIN,
that is a different matter. But you said you just did a simple
BEGIN. And in that case, the nothing visible to other database
connections ever gets touched.
This leads me to conjecture that you have multiple threads
messing with the same database connection....
--
D. Richard Hipp <[EMAIL PROTECTED]>
Is it conceivable that the autocommit flag could actually be a semaphore
or similar so that BEGIN would actually queue the transaction and
resolve the clash? The problem of thread interaction appears to puzzle
many users so moving the solution into Sqlite rather than expecting the
application to handle it might be better partitioning.
I realize that every extra feature like that detracts from "Lite" and
burdens simple embedded applications, so it could perhaps be an option.
