22 Feb
2014
22 Feb
'14
9:19 a.m.
Hi Holger,
On Fri, Feb 21, 2014 at 4:53 PM, Holger Hans Peter Freyther
<holger(a)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