> On Apr 25, 2019, at 6:09 PM, Lullaby Dayal <lullaby.tec...@gmail.com> wrote: > > A single database connection is shared > among all these services. More than one service access the service API to > read/write database at the same time. No locking is implemented in our > service accessing the database.
The one issue that comes to mind is transactions: your design has no isolation (the I in ACID) between threads. In more detail: if a thread executes "BEGIN", does some inserts/updates/deletes, and then executes "END", other threads that issue SQLite calls at the same time will see the uncommitted changes being made by the first thread. Depending on your design, this can cause problems, especially if the first thread ever ends up aborting the transaction (leaving the other threads with stale data that isn't in the database.) It gets even more "fun" if the secondary threads are making their own changes (without BEGIN/END), because those changes will become part of the first thread's transaction, so if the first thread aborts, the other threads' changes will be lost. For this reason it's usually good to have a mutex for transactions: you lock the mutex before calling BEGIN and unlock it after calling END. (If you make one-off changes without BEGIN/END, you have to lock the mutex around those calls too.) If this isn't a problem for you because you never use transactions, then you may have a different problem: write performance. Issuing multiple writes without a transaction is inefficient, because each write has to begin and commit its own transaction, and the commits tend to be expensive (depending on the filesystem) because they have to ensure durability. —Jens _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
