I have this case:
Thread 1 Thread 2
------------------------------
BEGIN EXCLUSIVE
BEGIN EXCLUSIVE -> BUSY
... etc ...
BEGIN EXCLUSIVE -> BUSY
COMMIT
BEGIN EXCLUSIVE -> OK
...
The commit statement of Thread 1 will sometimes fail with a BUSY error.
A simple workaround is to try the commit a couple times if you receive
a BUSY error. Having done this, I cannot get this test to fail anymore.
However, how many people realize this? It was, to me, an unexpected scenario.
Would it not be better if the DB tried harder to make that COMMIT succeed,
if it knows that it has an EXCLUSIVE lock? I realize this might be murky
territory, since raising some magic number just pushes the failure cases
further from the realm of 'likely to encounter in ad-hoc testing', but I
thought I should bring this up anyway.
Regards,
Ben
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
