2008/8/24 Mihai Limbasan <[EMAIL PROTECTED]>:
> Bruno Moreira Guedes wrote:
>> And even with too many 'locking concurrency', I've done some stress
>> testing and SQLite still very well. I've thrown the SQLITE_BUSY errors
>> to a retry algorithm, which waits a random time in a time range and
>> try
Bruno Moreira Guedes wrote:
> And even with too many 'locking concurrency', I've done some stress
> testing and SQLite still very well. I've thrown the SQLITE_BUSY errors
> to a retry algorithm, which waits a random time in a time range and
> try again until a high number of retries. Using it, I've
> On Fri, Aug 22, 2008 at 7:47 PM, Bruno Moreira Guedes
> <[EMAIL PROTECTED]>wrote:
>
>> Hello,
>>
>> I have an application which uses SQLite. The program open a sqlite
>> database, and have about five instances running at the same time. For
>> each instance, it waits for user commands(where the 'u
Bruno,
I'm quite new to sqlite but I believe that concurrency may be an issue only
for data changes which require db locking. As long as you go with SELECTs,
there's not much to worry about.
Tomas
On Fri, Aug 22, 2008 at 7:47 PM, Bruno Moreira Guedes
<[EMAIL PROTECTED]>wrote:
> Hello,
>
> I hav
4 matches
Mail list logo
