[sqlite] BUSY on COMMIT when EXCLUSIVE is held is an unexpected result
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
Re: [sqlite] BUSY on COMMIT when EXCLUSIVE is held is an unexpected result
On 12/17/2010 07:54 PM, Ben Harper wrote: 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. I'm not sure how you got this to happen. One way is to try the COMMIT from within a user-defined function executed by a write statement - but that's not terribly likely. Were you using WAL mode? Or regular rollback mode (the default)? ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] BUSY on COMMIT when EXCLUSIVE is held is an unexpected result
I'm using rollback - and no it's nothing like trying to commit inside a user-defined function. Very simple usage pattern. I'll isolate the code so that it's small enough to post here. I just noticed that I do sqlite3_busy_timeout(DB,0) - if that's relevant. Ben -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Dan Kennedy Sent: 17 December 2010 03:53 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] BUSY on COMMIT when EXCLUSIVE is held is an unexpected result On 12/17/2010 07:54 PM, Ben Harper wrote: 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. I'm not sure how you got this to happen. One way is to try the COMMIT from within a user-defined function executed by a write statement - but that's not terribly likely. Were you using WAL mode? Or regular rollback mode (the default)? ___ 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
