Problem with ALTER SESSION RESET on Firebird 6

[Mark Rotteveel]

I'm seeing some issues with ALTER SESSION RESET on Firebird 6 (using
Jaybird), executing it results in error "Cannot reset user session;
There are open transactions (2 active)".

Given the way Jaybird works, there is normally only one active
transaction. These tests pass on Firebird 6.0.0.1283 (from September
2025), and fail on 6.0.0.1829 and 1843, which suggests this is due to
changes in Firebird.

Is there some (relatively) recent change (probably this month or end of
February) that cause Firebird to keep a connection-bound transaction
server-side or not correctly end transactions on commit?

Mark

PS Sorry for the wide gap between versions, but I recently moved my
desktop to Linux, and I have some problems running all tests there, and
my remaining Windows laptop wasn't used often, so it doesn't have a lot
of snapshots. I might be able to pull some intermediate versions from a
backup of my desktop, but even those have a big gap in versions.
--
Mark Rotteveel

[Alex Peshkoff]

On 3/20/26 12:36, 'Mark Rotteveel' via firebird-devel wrote:
> I'm seeing some issues with ALTER SESSION RESET on Firebird 6 (using
> Jaybird), executing it results in error "Cannot reset user session;
> There are open transactions (2 active)".
>
> Given the way Jaybird works, there is normally only one active
> transaction. These tests pass on Firebird 6.0.0.1283 (from September
> 2025), and fail on 6.0.0.1829 and 1843, which suggests this is due to
> changes in Firebird.
>
> Is there some (relatively) recent change (probably this month or end
> of February) that cause Firebird to keep a connection-bound
> transaction server-side or not correctly end transactions on commit?

Yes, metadata read transaction.
I will take care of it.

[Mark Rotteveel]

Thanks!

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

Alex Peshkoff wrote 20.03.2026 10:39:
> Yes, metadata read transaction.

I wonder if metadata should be read in user transaction for consistency...

--
WBR, SD.

[Alex Peshkoff]

It was initial approach. But we need RC transaction, and user transaction often not satisfies that. Moreover, consistency of shared cache hardly can be guaranteed with use of current transaction from current attach - we should satisfy wider requirements.

[Dimitry Sibiryakov]

Alex Peshkoff wrote 20.03.2026 10:48:
> It was initial approach. But we need RC transaction, and user transaction often
> not satisfies that.

Is this need for backward compatibility only or there is a practical reason
for metadata to have different visibility rules from data?

--
WBR, SD.

[Dimitry Sibiryakov]

Alex Peshkoff wrote 20.03.2026 10:48:
> Moreover, consistency of */shared/* cache hardly can be guaranteed with use of

> current transaction from current attach - we should satisfy wider requirements.

The cache is versioned, right? Metadata read in a transaction get version as
visible in this transaction and isn't mixed with others, no?..

--
WBR, SD.

[Alex Peshkoff]

Backward compatibility was enough reason for me not to analyze something
else.

[Alex Peshkoff]

Yes - but that's wrong approach.

Imagine relation added in transaction N of CS. Another process starts transactions N+1 and N+2. Transaction N+2 reads relation info from DB, puts it into cache - and according to suggested logic transaction N+1 has no access to it. 

[Dimitry Sibiryakov]

Alex Peshkoff wrote 20.03.2026 11:05:
> Imagine relation added in transaction N of CS. Another process starts
> transactions N+1 and N+2. Transaction N+2 reads relation info from DB, puts it
> into cache - and according to suggested logic transaction N+1 has no access to it.

I actually would had have value of RDB$RECORD_VERSION from RDB$RELATIONS on
mind...
Besides, even in described case this problem is solved automatically by cache
warmth up so "false miss" is temporary.

--
WBR, SD.