Wow this sounds exactly like my post of a few days ago titled "Strange
sqlite_busy deadlock behavior".
On Sat, Apr 11, 2009 at 7:11 AM, <m...@mwlabs.de> wrote:
> Hi,
>
> I'm using the latest amalgation of sqlite on Windows NTFS, compiled with
> SQLITE_THREADSAFE=1, from Visual C++.
>
> I have two threads which update a database.
> Each thread uses sqlite_open_v2 to open a connection.
> Both threads do essentially this:
>
> if BEGIN EXCLUSIVE TRANSACTION successful then {
> INSERT INTO...
> DELETE FROM...
> COMMIT
> }
>
> In the scenario I'm facing thread A blocks (as expected) in the BEGIN
> EXCLUSIVE CALL and waits.
> Thread B successfully opens the exclusive transaction, but then fails with
> SQLITE_BUSY in the INSERT INTO (in the step() function).
> How can this be?
>
> My wrapper class uses a busy handler, and waits for quite a long time for
> the lock to unblock. But it never unblocks. And this is within a
> successfully opened exclusive transaction.
>
> As far as I understood the documentation, BEGIN EXCLUSIVE makes sure that
> no
> other thread/process has locks open etc. If it returns success, other
> operations from within the same thread using the same connection cannot
> fail
> with SQLITE_BUSY...
>
> What do I overlook here? I'm puzzling with this for two days now, but
> without success...
>
> Thanks in advance for your ideas.
>
>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
