Richard Klein wrote:
Requiring the second transaction to complete first is expected in
terms of SQLIte's concurrency system.
So in terms of using SQLite, I need to close the entire transaction
and restart it when I get a "database locked" return code in a writer
thread? It's not enough to
In a threaded environment the simple and effective solution is to
synchronize your transactions with a mutex. You lose a little possible
concurrency but if you do not need it you simplify the logic no end and
have a more robust application.
Using pthreads you can improve a little by using
On 1/2/08, Lior Okman <[EMAIL PROTECTED]> wrote:
> Trevor Talbot wrote:
> > Requiring the second transaction to complete first is expected in
> > terms of SQLIte's concurrency system.
> So in terms of using SQLite, I need to close the entire transaction and
> restart it when I get a "database
Requiring the second transaction to complete first is expected in
terms of SQLIte's concurrency system.
So in terms of using SQLite, I need to close the entire transaction and
restart it when I get a "database locked" return code in a writer
thread? It's not enough to just retry the commit in
Trevor Talbot wrote:
On 1/2/08, Lior Okman <[EMAIL PROTECTED]> wrote:
I'm using SQLite3 version 3.4.2 (latest in Debian testing and unstable),
and I have a scenario using transactions in SQLite3 that is a bit
counter-intuitive.
You'll want to look at http://sqlite.org/lockingv3.html
On 1/2/08, Lior Okman <[EMAIL PROTECTED]> wrote:
> I'm using SQLite3 version 3.4.2 (latest in Debian testing and unstable),
> and I have a scenario using transactions in SQLite3 that is a bit
> counter-intuitive.
You'll want to look at http://sqlite.org/lockingv3.html for this.
> I open an
Try your test using a "begin Immediate" instead of begin.
A write lock is not taken out until the very last moment (ie a spill to disk
or commit).
Lior Okman <[EMAIL PROTECTED]> wrote:
Hi,
I'm using SQLite3 version 3.4.2 (latest in Debian testing and unstable),
and I have a scenario
Hi,
I'm using SQLite3 version 3.4.2 (latest in Debian testing and unstable),
and I have a scenario using transactions in SQLite3 that is a bit
counter-intuitive.
I open an SQLite3 database from two terminals. In the first terminal I
run the following SQLs:
> $ sqlite3 test.db
>
8 matches
Mail list logo