Tino Lange wrote:
> Hi Marcus,
>
> I have no problem when the reading application gets a lock error because the
> writing application has a lock.
>
> But the problem is the other way around:
> -> The writing application gets a lock error because someone reads!
well... since the writer blocks t
low readers and
writers to co-exist with out locking each other out.
--- On Thu, 7/2/09, Tino Lange wrote:
> From: Tino Lange
> Subject: Re: [sqlite] SQLite3: Database is sometimes locked when a reader is
> attached with open_v2
> To: sqlite-users@sqlite.org
> Date: Thursday, Jul
Hi Marcus,
I have no problem when the reading application gets a lock error because the
writing application has a lock.
But the problem is the other way around:
-> The writing application gets a lock error because someone reads!
This is what I can't understand and what I didn't expect. I would
>From http://www.sqlite.org/lockingv3.html:
--
Eventually, the writing process will want to update the database file,
either because its memory cache has filled up or because it is ready
to commit its changes. Before this happens, the writer must make sure
no ot
I'm afraid this is by design of sqlite: Sqlite will lock
the database during a writing transaction, I think no matter
if you open a 2nd connection using the readonly flag.
the typical solutions are:
a) retry your read attempt after you receive a busy error code until
it proceeds.
b) consider s
Hi all,
I have written a program that opens a SQLIte3 database and writes in it most
of the time via replace/update.
If I do select like (no writes, really only reads) statements from some
other process that carefully opens the database with "sqlite3_open_v2(...,
SQLITE_OPEN_READONLY, ...)" th
6 matches
Mail list logo
