3 ms·
Can someone explain a bit more? (a) Does this mean that there will be an sqlite version that can be deployed as a process accessible over network in servers?
by deepakprakash 8y ago
Can someone explain a bit more?
(a) Does this mean that there will be an sqlite version that can be deployed as a process accessible over network in servers?
(b) Does this mean that sqlite will now have the capability to do concurrent reads/writes, but that it is upto users to implement a process that can take advantage of this and create something like (a)?
- dragonwriter 8y agoThis provides (b), not (a).
- X-Istence 8y ago> (a) Does this mean that there will be an sqlite version that can be deployed as a process accessible over network in servers? No. > (b) Does this mean that sqlite will now have the capability to do concurrent reads/writes, but that it is upto users to implement a process that can take advantage of this and create something like (a)? Yes... this allows a multi-threaded application for example to have multiple readers/writers without blocking each other.
- hd4 8y agoFor some reason, I had the idea that this was always the case with SQLite, at least for the last 10 years or so.
- blattimwind 8y agoIn WAL mode, readers don't block writers and vice versa, but there can still only be one writer active at any given time.
- nbevans 8y ago... as long as those threads don't touch the same page as each other. Page locks <> row locks.
- blattimwind 8y agoDepends on the width of your rows and the relation of access patterns to physical row allocation.