[PATCH] db: use WAL journaling mode for higher concurrency

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Alexey Shamrin shamrin at gmail.com
Sat Feb 22 08:19:09 UTC 2014


Hi Holger,

On Fri, Feb 21, 2014 at 4:53 PM, Holger Hans Peter Freyther
<holger at freyther.de> wrote:
> the answer right now is really not to access the database/tables from outside.

Thank you! I was under impression that OpenBSC was locking *itself*
from database file. But this is obviously wrong, OpenBSC is
single-threaded. I now know there was another script periodically
querying SQLite file.

That said, it's not practical to never touch DB from outside and use
only OpenBSC VTY interface. The latter doesn't allow custom SQL
queries. Fortunately, the workaround is simple: issue `PRAGMA
journal_mode = WAL` from `sqlite3` command once, when deploying
OpenBSC.

> So the "fix" is really just a workaround and WAL does not come for free either.

As far as I can tell, most disadvantages of WAL [1] don't concern
OpenBSC. Possibly except the need to have write privileges to DB
directory in order to read from WAL database.

> In case you want to improve the database code please have
> a look here[1]. In the long run our interface should be async, we should
> use the DB APIs directly, use prepared statements, etc.
> [1] http://openbsc.osmocom.org/trac/wiki/Tasks/NITBAsyncDatabase

Yes, but switching the async interface alone won't fix the 'database
is locked' problem. Only if we also switch to MySQL/Postgres. What do
you mean by "use the DB APIs directly"?

[1]: https://www.sqlite.org/draft/wal.htm

Alexey




More information about the OpenBSC mailing list