[sqlite] Transactions/locks in WAL mode

On 10 Jun 2015, at 5:42pm, Clemens Ladisch wrote: > The documentation talks about writing as the primary reason for locks, > but read-only transactions need to take a read lock. Two (automatic) > transactions imply two lock/unlock operations. True. But still a bad reason to use BEGIN and

[sqlite] Transactions/locks in WAL mode

Olivier Vidal wrote: > In terms of pure performance, is that there is a difference between: > > - SELECT > - SELECT > (so two read transactions) > > AND > > - BEGIN > - SELECT > - SELECT > - END The documentation talks about writing as the primary reason for locks, but read-only transactions need

[sqlite] Transactions/locks in WAL mode

ok, thank you Clemens and Kevin. another question please. In terms of pure performance, is that there is a difference between: - SELECT - SELECT (so two read transactions) AND - BEGIN - SELECT - SELECT - END olivier > Simon Slavin > 10 juin 2015 14:39 > > In

[sqlite] Transactions/locks in WAL mode

Thank you Simon! It's the first response I get, can anyone send me the Clemens's answer please? I do not know why I have not received. I hope I did not miss other responses. olivier > Simon Slavin > 10 juin 2015 14:39 > > In addition to Clemens' excellent

[sqlite] Transactions/locks in WAL mode

On 10 Jun 2015, at 2:00pm, Olivier Vidal wrote: > It's the first response I get, can anyone send me the Clemens's answer > please? I do not know why I have not received. I hope I did not miss other > responses. Probably got marked by your software as spam. Check in your junkmail folder.

[sqlite] Transactions/locks in WAL mode

On 10 Jun 2015, at 9:48am, Olivier Vidal wrote: > SELECT > UPDATE > In this example, the set of these commands is serialized? The two commands > act on the same snapshot? So, two commands have the same data (same > snapshot), but those data may be modified by another thread/process between >

[sqlite] Transactions/locks in WAL mode

Olivier Vidal wrote: > UPDATE > Internally, is the same thing that: BEGIN DEFERRED - UPDATE -COMMIT? Yes. > SELECT > UPDATE > In this example, the set of these commands is serialized? Assuming that you finalize the SELECT before executing the UPDATE, this is the same as BEGIN SELECT COMMIT

[sqlite] Transactions/locks in WAL mode

Hello, some questions please about transactions/locks in a multithreaded environment, multiple applications, WAL mode, NO shared cache, NO read_uncommitted pragma: Some examples: 1- UPDATE Internally, is the same thing that: BEGIN DEFERRED - UPDATE -COMMIT? 2- SELECT UPDATE In