stablished than the later.
>
> Again thanks for the information and I apologize for taking up so much list
> bandwidth. I hope others can benefit.
>
> John
>
> --- On Thu, 5/12/11, Pavel Ivanov wrote:
>
>> From: Pavel Ivanov
>> Subject: Re: [sqlite] Common Multi
nks,
John
--- On Fri, 5/13/11, Simon Slavin wrote:
> From: Simon Slavin
> Subject: Re: [sqlite] Common Multi-treaded Problem
> To: "General Discussion of SQLite Database"
> Date: Friday, May 13, 2011, 9:05 PM
>
> On 14 May 2011, at 12:29am, John Deal wrote:
>
On 14 May 2011, at 12:29am, John Deal wrote:
> I actually never finalize prepared statements until the DB is closed and not
> being used anymore. I reset the prepared statements. For writes (inserts,
> updates, etc.) I use explicit transactions with commits (or rollbacks if
> errors). I reu
On Fri, 13 May 2011 17:14:32 -0700 (PDT)
John Deal wrote:
> Again thanks for the information and I apologize for taking up so much list
> bandwidth. I hope others can benefit.
Watching this thread was useful to me and I'd like to use this reply to *thank*
Pavel and the
other guys for explaini
implementation of the former was
more established than the later.
Again thanks for the information and I apologize for taking up so much list
bandwidth. I hope others can benefit.
John
--- On Thu, 5/12/11, Pavel Ivanov wrote:
> From: Pavel Ivanov
> Subject: Re: [sqlite] Common Multi-treaded P
should be doing.
Thanks,
John
--- On Thu, 5/12/11, Simon Slavin wrote:
> From: Simon Slavin
> Subject: Re: [sqlite] Common Multi-treaded Problem
> To: "General Discussion of SQLite Database"
> Date: Thursday, May 12, 2011, 9:28 PM
>
> On 13 May 2011, at 1:33am,
> Pavel, could you please specify what do you mean by "statements in this
> transaction"? Statements
> that were prepared (sqlite3_prepare) or initiated (sqlite3_step) during the
> transaction?
Statements that were initiated during the transaction.
> Also, is this something that one should imme
If you don't mind, John, for bullying in the discussion...
On Thu, 12 May 2011 17:58:40 -0400
Pavel Ivanov wrote:
> There's no dependency between different prepared statements, but there
> is dependency between transactions as they use the same database. And
> transaction cannot be finished (imp
select prepared statement will lock the DB from other threads
> (or is it DB connections?) but not the current thread (or is it DB
> connection).
>
> Thanks for the help!
>
> John
>
> --- On Thu, 5/12/11, Pavel Ivanov wrote:
>
>> From: Pavel Ivanov
>> Sub
On 13 May 2011, at 1:33am, John Deal wrote:
> Humm. Resetting each prepared statement right after use seemed to work. So
> in review, a select prepared statement will lock the DB from other threads
> (or is it DB connections?) but not the current thread (or is it DB
> connection).
I don't t
, Pavel Ivanov wrote:
> From: Pavel Ivanov
> Subject: Re: [sqlite] Common Multi-treaded Problem
> To: "General Discussion of SQLite Database"
> Date: Thursday, May 12, 2011, 5:58 PM
> > Interesting is the impression I
> had with prepared statements was the reset was
wrote:
> From: Pavel Ivanov
> Subject: Re: [sqlite] Common Multi-treaded Problem
> To: "General Discussion of SQLite Database"
> Date: Thursday, May 12, 2011, 5:58 PM
> > Interesting is the impression I
> had with prepared statements was the reset was only
>
--- On Thu, 5/12/11, Igor Tandetnik wrote:
>
>> From: Igor Tandetnik
>> Subject: Re: [sqlite] Common Multi-treaded Problem
>> To: sqlite-users@sqlite.org
>> Date: Thursday, May 12, 2011, 12:35 PM
>> On 5/12/2011 12:31 PM, John Deal
>> wrote:
>> >
plete transactions.
Anyway, thanks for the insight.
John
--- On Thu, 5/12/11, Igor Tandetnik wrote:
> From: Igor Tandetnik
> Subject: Re: [sqlite] Common Multi-treaded Problem
> To: sqlite-users@sqlite.org
> Date: Thursday, May 12, 2011, 12:35 PM
> On 5/12/2011 12:31 PM, John Deal
>
On 5/12/2011 12:31 PM, John Deal wrote:
> When I allow multiple readers with each thread using a different DB
> connection (open with the same flags) and each thread having
> exclusive use of its DB connection (no sharing of connections) and if
> more than one thread is reading the DB at the same t
15 matches
Mail list logo