Project

General

Profile

Actions

Bug #30

closed

sqlite3 database / asynchronous access to it

Added by laforge about 8 years ago. Updated about 7 years ago.

Status:
Closed
Priority:
Urgent
Assignee:
Category:
OpenBSC
Start date:
Due date:
% Done:

0%

Resolution:
duplicate
Spec Reference:

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

Related to OsmoNITB - Feature #1592: VLR in libmsc, to connect to HLR asynchronouslyClosedneels02/23/2016

Actions
Related to OsmoNITB - Bug #1591: libdbi is buggy and slow, get rid of itClosedneels02/23/2016

Actions
Actions #1

Updated by laforge almost 8 years ago

  • Status changed from New to In Progress
Actions #2

Updated by laforge almost 8 years ago

  • Related to Feature #1592: VLR in libmsc, to connect to HLR asynchronously added
Actions #3

Updated by laforge almost 8 years ago

  • Priority changed from High to Urgent
Actions #4

Updated by laforge over 7 years ago

  • Assignee changed from laforge to neels
Actions #5

Updated by laforge over 7 years ago

  • Target version set to Asynchronous HLR+AUC for CS
Actions #6

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

Actions #7

Updated by neels over 7 years ago

  • Related to Bug #1591: libdbi is buggy and slow, get rid of it added
Actions #8

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.

Actions #9

Updated by neels about 7 years ago

  • Status changed from In Progress to Closed
  • Resolution set to duplicate

With the libvlr / OsmoHLR effort tracked in #1592, keeping this ticket does not really make sense anymore.
When #1592 is done, access to the HLR data will be inherently asynchronous, via GSUP messaging.
(The SMS related issue shall be tracked in #1591 and is merely temporary anyway.)

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)