On 14 February 2011 10:57, Henning Basold <[email protected]> wrote: > Am 14.02.2011 11:56, schrieb Henning Basold: >> Am 27.01.2011 08:40, schrieb Henning Basold: >>> >>> Hi, >>> >>> I recently ran into a problem with prepared statements in SQLite3. >>> >>> I use a prepared statement with long life time because it's very complex >>> and not executed concurrently. But after execution no modifying statements >>> could be executed in that database because it was locked. >>> >>> After some investigation I found >>> http://www.sqlite.org/cvstrac/wiki?p=DatabaseIsLocked . So sqlite3_reset has >>> to be called on the statement. As the library has no knowledge about the >>> point in time the statement is no longer needed (multi-row sets etc.), I >>> thought something like an explicit reset is needed. >>> >>> I attached a patch which introduces a reset method on statements. It has >>> a no-op implementation for all backends except SQLite. The patch also >>> contains a test case which does not run without the reset. It leads to the >>> error "SOCIERROR: sqlite3_statement_backend::loadOne: database is locked". >>> >>> All this is tested on Windows XP and Ubuntu 10.10 with SQLite 3.7.2. >>> >>> Best Regards >>> Henning >> >> >> Hi, >> >> as there was no response I retry my request for the integration of the >> patch. The main problem I had was explained in my last mail. >> >> But I must admit that my statement "the library has no knowledge about the >> point in time the statement is no longer needed" was made a bit fast. >> Attached is a revised patch. It is an extension of the last. The "reset" >> methods are preserved as the backend really does not know when to reset the >> statement. But a call to it is added to the destructor of the "statement" >> class. So if one uses a prepared statement she is encouraged to make a copy >> of the statement. This is some kind of "guard" which can do the reset >> automatically. >> >> Also a bug was fixed (call on a deleted backend) and "reset" should not >> throw any longer because it is called inside a destructor. >> >> Finally I have updated the docs. >> >> Hopefully this patch gets applied as I can not reuse the prepared >> statement in my application. >> >> Best regards >> Henning > > Ouch, > forgot the patch ....
I'm sorry that this patch has been forgotten for sooo long... But, every contribution is precious, so I've reworked it in dedicated branch with corresponding ticket: https://github.com/SOCI/soci/issues/52 Thanks! Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
