On Sat, Nov 23, 2019 at 4:17 PM Dan Kennedy wrote:
> > [...] Why is thread_B blocked when doing a read just because SQLite is
> writing to another table? [...]
> > Is this the expected behavior or am I doing something stupid in my code.
> And if so, what to check?
>
> This should only happen if
On 24/11/62 00:05, Jens Alfke wrote:
On Nov 23, 2019, at 7:17 AM, Dan Kennedy wrote:
This should only happen if you are using shared-cache mode. Don't use
shared-cache mode.
Shared-cache mode also breaks Isolation between connections — during a
transaction, other connections will see the
That's very helpful, thank you very much, Daniel. Also to Jens.
I've re-read the SQLite documentation for shared cache now. I guess I had
enabled it in the past to increase the performance (many threads in my
application).
Apparently, this had the opposite effect :-/
After disabling the
> On Nov 23, 2019, at 7:17 AM, Dan Kennedy wrote:
>
> This should only happen if you are using shared-cache mode. Don't use
> shared-cache mode.
Shared-cache mode also breaks Isolation between connections — during a
transaction, other connections will see the writer’s intermediate state.
On 23/11/62 17:02, Mario M. Westphal wrote:
I have an issue with concurrency. This may be the intended behavior of
SQLite. Or I'm doing something wrong.
If somebody could shed a light, I would be thankful.
I compile and use SQLite on Windows with VStudio.
I compile it with
> If I have 2 separate processes, 1 of which will attempt to Read and Write a
> Database (Process A)
> and the 2nd which will only Read the database (Process B), then if Process A
> is in the middle of a Write when Process B tries to read what will happen?
If Process A is in the middle of writing
6 matches
Mail list logo
