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

[NIkolai Marchenko]

In short: with the addition of this check .load() became unusable in any
sort of delayed loading because now you have to *know* whether you are
doing it in the same thread, which is just not realistic.

On Wed, Feb 19, 2025 at 2:08 AM NIkolai Marchenko <enmarantispam at gmail.com>
wrote:

> Fiddling with what I can do about this all I came across one point where
> this check is massively in the way and makes the code significantly more
> complicated. Where before you just needed to call .load() without caring
> about the new check and things just worked, you now have to write the
> construction like
>
> data = transaction.db()->load<Type>(data.objectId());
>
> to ensure that you are not hitting this new check and getting asserted.
> this just makes code  much more cumbersome and unintuitive
>
> On Tue, Feb 18, 2025 at 4:19 PM NIkolai Marchenko <enmarantispam at gmail.com>
> wrote:
>
>> 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 . This was a basis of what I was doing
>> in my code and it worked fine previously.
>>
>> In fact there are two distinct paths that are now causing issues that
>> worked in 2.4:
>>
>> 1) Loading an internal lazy object in a separate thread via .load()
>> compared to where the original outside lazy object was acquired
>> 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..
>>
>> It's possible that both of those were mishandling of the library on my
>> side that were never checked, but they have been working flawlessly for 2
>> years so now I am left scratching my head about what would be a correct
>> path of dealing with it.
>>
>> On Tue, Feb 18, 2025 at 12:37 PM Boris Kolpackov <boris at codesynthesis.com>
>> wrote:
>>
>>> NIkolai Marchenko <enmarantispam at gmail.com> writes:
>>>
>>> > I am getting this error:
>>> >
>>> >
>>> /home/zeks/odbbuild/libodb-gcc-9/libodb-gcc-9/libodb-2.5.0/odb/transaction.cxx:340:
>>> > virtual odb::connection&
>>> >
>>> odb::transaction_impl::connection(odb::transaction_impl::database_type*):
>>> > Assertion `db == 0 || db == &database_' failed.
>>>
>>> This is a "sanity check" that makes sure you don't use a transaction that
>>> was started on a different database instance. This check is actually new
>>> in 2.5.0, I see it's not present in 2.4.0. So maybe it is catching an
>>> error on your side?
>>>
>>> The only significant threading-related change in ODB 2.5.0 is that we
>>> have switched to C++11 threads. In ODB 2.4.0 we used POSIX threads on
>>> POSIX and Win32 threads on Windows. But I don't think this should matter,
>>> even if you are using the POSIX API for TLS.
>>>
>>>
>>> > This happens modestly in thread workers, my code is keeping
>>> thread_local
>>> > instance of odb::transaction obtained with db->begin().
>>>
>>> It would be interesting to see if database_ points to a valid database
>>> instance.
>>>
>>