Bug #30
closedsqlite3 database / asynchronous access to it
0%
Description
Sometimes we want to access the database but it might be locked, or the data might require reading some data off disk.
Due to the single-threaded non-blocking architecture of bsc_hack, this may cause all kinds of problems.
Either we have to treat the database as a separate process to which we send messages, or we have to simply cache all the data in RAM and only update the on-disk cache whenever convenient and/or at program exit time.
Related issues
Updated by laforge about 8 years ago
- Related to Feature #1592: VLR in libmsc, to connect to HLR asynchronously added
Updated by laforge over 7 years ago
- Target version set to Asynchronous HLR+AUC for CS
Updated by neels over 7 years ago
I take it that once libvlr is in place, there will be no sqlite3 in osmo-nitb/osmo-cscn.
-> watch #1592
Updated by neels over 7 years ago
- Related to Bug #1591: libdbi is buggy and slow, get rid of it added
Updated by neels over 7 years ago
neels wrote:
I take it that once libvlr is in place, there will be no sqlite3 in osmo-nitb/osmo-cscn.
Correction: there will be no integrated HLR in a directly used sqlite3 db. We will still
keep the SMS in an sqlite3 db, but synchronous access for SMS is not a problem.
With #1592 resolved, we should still verify beyond doubt that the sms queue will not block
on e.g. a locked sqlite3 db.
Updated by neels over 7 years ago
- Status changed from In Progress to Closed
- Resolution set to duplicate