One means of troubleshooting this is to emit a log statement that
includes the thread id with every BEGIN/COMMIT (e.g. printf("%d - %s",
thread, sql)). It may be useful to log other sql statements this way as
well.
This sort of troubleshooting has always shown the mistake to be mine,
not SQLite when I see this issue.
Pat
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 06, 2006 6:36 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Problems with multiple threads?
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]>
