Re: [sqlite] Problem with concurrent transaction and DETACH DATABASE

2012-06-21 Thread Jay A. Kreibich
On Thu, Jun 21, 2012 at 09:53:57AM +0100, Pontus Bergsten scratched on the wall: > It seems that it is very important that every statement evaluation is > concluded with a sqlite3_reset() (or sqlite3_finalize() if the statement > is not going to be used anymore). That's true, and as others

Re: [sqlite] Problem with concurrent transaction and DETACH DATABASE

2012-06-21 Thread Pontus Bergsten
ickat: torsdag, 21 juni 2012 13:46 Ämne: Re: [sqlite] Problem with concurrent transaction and DETACH DATABASE On 21 Jun 2012, at 9:53am, Pontus Bergsten <pontus_bergs...@yahoo.se> wrote: > were it was stated that > > "You should be in the habit of calling sqlite3_reset()

Re: [sqlite] Problem with concurrent transaction and DETACH DATABASE

2012-06-21 Thread Simon Slavin
On 21 Jun 2012, at 9:53am, Pontus Bergsten wrote: > were it was stated that > > "You should be in the habit of calling sqlite3_reset() on each query as soon > as that query finishes. Otherwise the query *might* leave a read-lock on the > database file and thus

Re: [sqlite] Problem with concurrent transaction and DETACH DATABASE

2012-06-21 Thread Pontus Bergsten
; Skickat: onsdag, 20 juni 2012 17:45 Ämne: Re: [sqlite] Problem with concurrent transaction and DETACH DATABASE It looks to me that you have corrupted memory or already closed database at this point. AFAIK, ROLLBACK cannot return SQLITE_ERROR in any "normal" situation (I exclude su

Re: [sqlite] Problem with concurrent transaction and DETACH DATABASE

2012-06-20 Thread Pavel Ivanov
t; the query is executed. >>> >>> >>> Thread 1 is using transaction statements "BEGIN" and "COMMIT" to start and >>> commit transactions. As we know the commit statement in Thread 2 does not >>> fail. >>> >>> Any ideas?

Re: [sqlite] Problem with concurrent transaction and DETACH DATABASE

2012-06-20 Thread Pontus Bergsten
s Bergsten <pontus_bergs...@yahoo.se>; General Discussion of SQLite Database <sqlite-users@sqlite.org> Skickat: onsdag, 20 juni 2012 16:24 Ämne: Re: [sqlite] Problem with concurrent transaction and DETACH DATABASE Then something else should happen in your application

Re: [sqlite] Problem with concurrent transaction and DETACH DATABASE

2012-06-20 Thread Pavel Ivanov
________________ >>  Från: Pavel Ivanov <paiva...@gmail.com> >> Till: Pontus Bergsten <pontus_bergs...@yahoo.se>; General Discussion of >> SQLite Database <sqlite-users@sqlite.org> >> Skickat: onsdag, 20 juni 2012 14:27 >> Ämne: Re: [

Re: [sqlite] Problem with concurrent transaction and DETACH DATABASE

2012-06-20 Thread Pontus Bergsten
gt; commit transactions. As we know the commit statement in Thread 2 does not > fail. > > Any ideas? > > Pontus > > > > >  Från: Pavel Ivanov <paiva...@gmail.com> > Till: Pontus Bergsten <pontus_bergs...@yahoo.se>; General Discussi

Re: [sqlite] Problem with concurrent transaction and DETACH DATABASE

2012-06-20 Thread Pavel Ivanov
bergs...@yahoo.se>; General Discussion of > SQLite Database <sqlite-users@sqlite.org> > Skickat: onsdag, 20 juni 2012 14:27 > Ämne: Re: [sqlite] Problem with concurrent transaction and DETACH DATABASE > > Probably the following scenario is possible in your situation: > - thread 1 lo

Re: [sqlite] Problem with concurrent transaction and DETACH DATABASE

2012-06-20 Thread Pontus Bergsten
Från: Pavel Ivanov <paiva...@gmail.com> Till: Pontus Bergsten <pontus_bergs...@yahoo.se>; General Discussion of SQLite Database <sqlite-users@sqlite.org> Skickat: onsdag, 20 juni 2012 14:27 Ämne: Re: [sqlite] Problem with concurrent transaction and DETACH DATABASE Pro

Re: [sqlite] Problem with concurrent transaction and DETACH DATABASE

2012-06-20 Thread Pavel Ivanov
Probably the following scenario is possible in your situation: - thread 1 locks transaction mutex - thread 1 inserts buffered data - thread 2 starts transferring data to Dest database - thread 1 tries to commit, commit fails (do you check return code from it?), transaction is left open - thread 1