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
