Re: boost.sqlite

From: Dominique Devienne (ddevienne_at_[hidden])
Date: 2024-01-05 14:46:53

On Fri, Jan 5, 2024 at 2:15 PM Phil Endecott via Boost <
boost_at_[hidden]> wrote:

> What do you do about multi-threaded usage?
>

Hi. What is there to do Phil? SQLite itself deals with that.
And even then, it depends how you build it, and even how you configure it
at runtime.

SQLite is inherently single-threaded, but can be thread-safe on its
connection (sqlite3*),
and can serialize access. Although most anything one does requires several
API calls,
even that serialization is probably not enough for correct usage.

It's much better and recommended in MT apps to either use one connection
per thread,
or do higher level serialization (thus not at the per-API level as SQLite
does).

Klemens' API is rather high level, with .execute() hiding multiple bind
calls, step()+reset() calls,
so he could I guess lock around that set of calls, but even that is not
enough for queries, since
getting the values from the resultset accesses the very same statement that
was executed.

Really it's the client code that has the full context and can do the
locking, if relevant. My $0.02. --DD