On 25 Sep 2015, at 2:39am, Allen wrote:
> I wanted
> to confirm the readers would work correctly while another connection
> held an EXCLUSIVE lock, because if they didn't, and the lock
> eventually went EXCLUSIVE automatically, that might be a problem,
Don't forget to have each connection set a
> Don't forget to have each connection set a timeout This makes SQLite
> automatically retry (using monotonic backoff) if the database is locked.
I had that set to 10 seconds using sqlite3_busy_timeout(db, 1).
That doesn't work in shared cache mode--in that mode, you immediately
get an SQ
On 25 Sep 2015, at 1:27am, Allen wrote:
>> Why on earth are you using BEGIN EXCLUSIVE?
>
> If WAL works "as advertised", I might as well go straight to EXCLUSIVE so I
> don't have to later escalate the lock from RESERVED to EXCLUSIVE. And it
> does work just fine, once I turned off the shared
> The problem with going to EXCLUSIVE manually is that you lock out other
> connections for longer than necessary.
I have only one connection that does writes. In any event, I wanted
to confirm the readers would work correctly while another connection
held an EXCLUSIVE lock, because if they didn
> Why on earth are you using BEGIN EXCLUSIVE?
If WAL works "as advertised", I might as well go straight to EXCLUSIVE so I
don't have to later escalate the lock from RESERVED to EXCLUSIVE. And it
does work just fine, once I turned off the shared cache mode.
> I was under the apparently mistaken impression that starting any
transaction would block writes, even in WAL mode.
My problem was that I was using sqlite3_enable_shared_cache(true). I
enabled this because I was under the impression that is required for
multiple connections to share an in-memory
On 24 Sep 2015, at 5:37pm, Allen wrote:
> I was under the apparently mistaken impression that starting any
> transaction would block writes, even in WAL mode.
In WAL mode, a writing connection writes to the journal. Other connections
will continue to read from the 'live' database. When the w
Allen wrote:
> 1. It would be nice to have read-only transactions for use with WAL
> databases. When a read-only transaction was started, it would take a
> "lock" on the WAL and then not advance further into the WAL until the
> transaction ended. Thus, all select statements issued while the read
> > WAL does this already. You just need to BEGIN a transaction when you
> want it to BEGIN and COMMIT or ROLLBACK when you are done with it.
>
> I was under the apparently mistaken impression that starting any
> transaction would block writes, even in WAL mode.
>
> Just to be clear, this would
> WAL does this already. You just need to BEGIN a transaction when you
want it to BEGIN and COMMIT or ROLLBACK when you are done with it.
I was under the apparently mistaken impression that starting any
transaction would block writes, even in WAL mode.
Just to be clear, this would work:
On mult
Suggestions for SQLite features:
1. It would be nice to have read-only transactions for use with WAL
databases. When a read-only transaction was started, it would take a
"lock" on the WAL and then not advance further into the WAL until the
transaction ended. Thus, all select statements issued wh
On Thursday, 24 September, 2015 08:53, Allen said:
> Suggestions for SQLite features:
> 1. It would be nice to have read-only transactions for use with WAL
> databases. When a read-only transaction was started, it would take a
> "lock" on the WAL and then not advance further into the WAL until
12 matches
Mail list logo
