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
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()
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
;
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
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?
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
____________
>> 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: [
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
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
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
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
In our application we have two threads implementing a signal logger
functionality, see pseudo code below.
Thread 1: Reads signal data, and log to a global in-memory SQLite database
after a pre-determined number of reads.
1 while( true )
2 {
3 // Buffer data, blocks until new data is
12 matches
Mail list logo