[odb-users] any significant changes to threading model in 2.5?

[Boris Kolpackov]

NIkolai Marchenko <enmarantispam at gmail.com> writes:

> Correct me if I am wrong: I was of the opinion that generating a new
> database object didn't do anything to an internal thread_local connection
> held by an odb::transaction instance.

The check was added to detect the following type of errors (using
SQLite database files for illustration):

database db1 ("db1.sqlite3");
database db2 ("db2.sqlite3");

transaction t (db1.begin ());
db2.load<object> ();

In 2.4 the above code would silently try to load the object from db1.


> 1) Loading an internal lazy object in a separate thread via .load()
> compared to where the original outside lazy object was acquired

I am not sure what you mean by "lazy objects". All ODB lazy mechanisms
(lazy pointers, lazy-loaded object sections) either embed the database
instance (lazy pointer) or expect you to pass the database explicitly
(sections). I don't believe we have any cases where you call load() and
it just uses whatever the current transaction might be.


> 2) Trying to persist an object in an odbcallbackhook that creates a new
> database object, but still uses the same odb::transaction, since, inside my
> framework, when it sees that a thread_local odb::transaction is already
> loaded it doesn't try to open a new transaction, but still creates a new
> odb::database..

Yes, this feels wrong. Conceptually, in ODB, a transaction belongs to
a connection and a connection belongs to a database. It seems in your
framework all instances of odb::database "point" to the same underlying
database and thus it doesn't matter "whose" transaction/connection you
are using. But this assumption does not hold generally.