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

[NIkolai Marchenko]

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.
>>
>