Re: [sqlite] How can a COMMIT attempt result in SQLITE_BUSY ?
Thank's Igor, uhh... I should have read this more carefully. I understand now that the commit may in fact need to wait for some other shared locks... sorry for the noise Marcus > Marcus Grimm wrote: >> I'm wondering how it can happen that after a successfull >> "BEGIN TRANSACTION;" statement and some inserts or update >> statements, that the final COMMIT failes with a busy error code ? >> >> Shouldn't that be impossible because there can be only one running >> transaction ? > > There may be multiple connections to the same database, each of which > could start a transaction. For more details, see > > http://sqlite.org/lockingv3.html > http://sqlite.org/lang_transaction.html > >> Everthing was working perfect until the user started a maintenance >> tool that opens a single connection to the same sqlite database >> while the server application was still running on the same hardware. >> Now it happends that the server was not able to get a >> COMMIT statement through > > You cannot commit any changes while another connection is reading from > the database. > > Igor Tandetnik > > > > ___ > 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
Re: [sqlite] How can a COMMIT attempt result in SQLITE_BUSY ?
Marcus Grimm wrote: > I'm wondering how it can happen that after a successfull > "BEGIN TRANSACTION;" statement and some inserts or update > statements, that the final COMMIT failes with a busy error code ? > > Shouldn't that be impossible because there can be only one running > transaction ? There may be multiple connections to the same database, each of which could start a transaction. For more details, see http://sqlite.org/lockingv3.html http://sqlite.org/lang_transaction.html > Everthing was working perfect until the user started a maintenance > tool that opens a single connection to the same sqlite database > while the server application was still running on the same hardware. > Now it happends that the server was not able to get a > COMMIT statement through You cannot commit any changes while another connection is reading from the database. Igor Tandetnik ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] How can a COMMIT attempt result in SQLITE_BUSY ?
Hello List, I'm wondering how it can happen that after a successfull "BEGIN TRANSACTION;" statement and some inserts or update statements, that the final COMMIT failes with a busy error code ? Shouldn't that be impossible because there can be only one running transaction ? I'm using shared cache and read_uncommitted = True inside a server application that opens multible connection to the same DB (similar to what can be found on the wiki pages under SampleCode). Everthing was working perfect until the user started a maintenance tool that opens a single connection to the same sqlite database while the server application was still running on the same hardware. Now it happends that the server was not able to get a COMMIT statement through (i.e. he timeout while trying this via sqlite3_step); with the result that he left a transaction open in one thread and was no longer able to do any writes into the sqlite database. After rebooting the server of course everthing was working back again. I'm able to reproduce this with a modified version of the SampleCode by just starting it two times: usually a COMMIT will timeout after a while. I know some workarounds for this (mainly to really make sure that a COMMIT can't be timed out anymore) but I'm curious if there is an explanation for this. Thank you Marcus Grimm ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
