Re: [sqlite] commit time

2009-10-24 Thread Tom Broadbent
To: General Discussion of SQLite Database Subject: Re: [sqlite] commit time thanks for the discussion. i'll keep my eyes open for lock contention. i'm going to start w/ the simple approach first and see how it goes. thanks tom -Original Message- From: sqlite-users-boun...@sqlite.org

Re: [sqlite] commit time

2009-10-22 Thread Tom Broadbent
: Wednesday, October 21, 2009 11:00 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] commit time Dangerous and disturbing this puzzle is. Only a bug could have locked those connections. If I discover anything useful I'll report it separately (no need to hijack this topic

Re: [sqlite] commit time

2009-10-22 Thread John Crenshaw
] On Behalf Of Dan Kennedy Sent: Thursday, October 22, 2009 1:27 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] commit time On Oct 22, 2009, at 11:37 AM, John Crenshaw wrote: > An open cursor will block. I've watched it. It was a major problem, > and > I spent

Re: [sqlite] commit time

2009-10-21 Thread Dan Kennedy
Dan. > > John > > -Original Message- > From: sqlite-users-boun...@sqlite.org > [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Dan Kennedy > Sent: Thursday, October 22, 2009 12:06 AM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] commit time

Re: [sqlite] commit time

2009-10-21 Thread John Crenshaw
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Dan Kennedy Sent: Thursday, October 22, 2009 12:06 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] commit time On Oct 22, 2009, at 5:21 AM, Tom Broadbent wrote: > if thread 1 opens a read cursor in read uncommitted mode it

Re: [sqlite] commit time

2009-10-21 Thread Dan Kennedy
ral Discussion of SQLite Database > Subject: Re: [sqlite] commit time > > Good, a single write thread saves you all the hassle involved with > yielding. Unfortunately, even without multiple writers blocking is > still > possible. If thread 1 opens a cursor, and thread 2 tries

Re: [sqlite] commit time

2009-10-21 Thread John Crenshaw
: Re: [sqlite] commit time if thread 1 opens a read cursor in read uncommitted mode it can block a write lock? i thought the read happens w/o a lock? -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of John Crenshaw Sent

Re: [sqlite] commit time

2009-10-21 Thread Tom Broadbent
:03 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] commit time Good, a single write thread saves you all the hassle involved with yielding. Unfortunately, even without multiple writers blocking is still possible. If thread 1 opens a cursor, and thread 2 tries to write before

Re: [sqlite] commit time

2009-10-21 Thread Tom Broadbent
Database Subject: Re: [sqlite] commit time Yes, you have to call sqlite3_enable_shared_cache before opening any database connections, then execute "PRAGMA read_uncommitted = true;" on each connection. Blocking can still happen in some situations, but you can handle it as I described in my orig

Re: [sqlite] commit time

2009-10-21 Thread Tom Broadbent
To: General Discussion of SQLite Database Subject: Re: [sqlite] commit time My understanding is that the shared cache allows table level locking for multiple threads in a single process, and can do so efficiently because the threads all share the same memory space, but if multiple processes attempt

Re: [sqlite] commit time

2009-10-21 Thread John Crenshaw
dbent Sent: Wednesday, October 21, 2009 12:03 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] commit time reading up on shared cache mode and found this: "The locking protocol used to arbitrate between multiple shared-caches or regular database users is described _else

Re: [sqlite] commit time

2009-10-21 Thread John Crenshaw
al Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Tom Broadbent Sent: Wednesday, October 21, 2009 12:05 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] commit time it sounds like this is the feature you recommend using: &

Re: [sqlite] commit time

2009-10-21 Thread Tom Broadbent
users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] On Behalf Of John Crenshaw [johncrens...@priacta.com] Sent: Tuesday, October 20, 2009 7:18 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] commit time Sounds like a great candidate for shared cache with PRAGMA read_uncommit

Re: [sqlite] commit time

2009-10-21 Thread Tom Broadbent
lite-users-boun...@sqlite.org] On Behalf Of John Crenshaw [johncrens...@priacta.com] Sent: Tuesday, October 20, 2009 7:18 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] commit time Sounds like a great candidate for shared cache with PRAGMA read_uncommitted = true. If other thread

Re: [sqlite] commit time

2009-10-20 Thread John Crenshaw
Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Tom Broadbent Sent: Tuesday, October 20, 2009 8:05 PM To: sqlite-users@sqlite.org Subject: [sqlite] commit time i have a simple join table containing two ids from two other tables. i have an index

[sqlite] commit time

2009-10-20 Thread Tom Broadbent
i have a simple join table containing two ids from two other tables. i have an index on each of the ids in the join table. CREATE TABLE ContentWordItem (word_id INT, item_id INT); CREATE INDEX idx_ContentWordItem_word ON ContentWordItem(word_id); // index to perform fast queries by