> So is such behavior documented and can be used or should I still avoid > keeping such "live" statements in db-shared enviroment?
It's documented that sqlite3_finalize AND sqlite3_reset release all locks acquired by the statement. So after resetting the statement you can keep it as long as you want, it won't block out any other process from accessing the database. Pavel On Thu, Feb 25, 2010 at 10:35 AM, Max Vlasov <max.vla...@gmail.com> wrote: > Hi, > > I thought that prepared statements in non-finalized state isn't compatible > with locking mechanism in db sharing environment i.e. if I want for any of > several processes not to hang waiting for EXCLUSIVE lock none of others > should use non-finalized prepared statements. But today I found that they > can coexist, but sqlite3_reset should be called (even if I'm not planning > new data reading). My simple test confirmed this: a writing process waited > getting SQLTE_BUSY results indefinitely and when another process called > sqlite3_reset (I'm sure this is the only sqlite api call performed fired by > button press), the first one successfully ended writing. > > So is such behavior documented and can be used or should I still avoid > keeping such "live" statements in db-shared enviroment? > > Platform: Windows > > Thanks > > Max > _______________________________________________ > 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
