Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> (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.



... as long as those threads don't touch the same page as each other. Page locks <> row locks.


Depends on the width of your rows and the relation of access patterns to physical row allocation.


For some reason, I had the idea that this was always the case with SQLite, at least for the last 10 years or so.


In WAL mode, readers don't block writers and vice versa, but there can still only be one writer active at any given time.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: