Migration from FB3 to FB4 and ReadConsistency=1

[gkvi...@gmail.com]

Hello

I have a FB3 database migrated to FB4. I use the standard configuration on FB4.

There are a problem with the OTI value when i run my program.

When ReadConsistency set to 1

See the attachmend Snap1-3.

Snap1. before start my program

Snap2. my program was started

Snap3. my program closed

Made a database sweep and restart my FB4 server with  ReadConsistency set to 0

See the attachmend Snap4-6.

Snap4. before start my program

Snap5. my program was started

Snap6. my program closed

is this a normal behavior of the FB4?

Thanks in advanced

Gregor

[Mark Rotteveel]

Please be explicit. What behaviour are you trying to ask about? Having
to read 6 screenshots and trying to infer what you're trying to ask
about can lead to miscommunication.

Mark
--
Mark Rotteveel

[gkvi...@gmail.com]

My problem is that the OTI value is lagging behind with each transaction that is started in my program. See Snap2 and Snap3.

Although when I look in the monitoring tables, neither a transaction nor an attachmend is active.

The OTI value remains, and the distance to the other values increases with each transaction, even when the program exits. As if there is still a transaction "hanging".

I never had problems with my program under FB3, after porting to FB4 I noticed this behavior. But with ReadConsistency=0 it is OK again, see Snap4-6.

[Dimitry Sibiryakov]

gkvi...@gmail.com wrote 14.11.2022 15:18:
> is this a normal behavior of the FB4?

If your application runs a never-ending RORC transaction then yes, it is
normal behavior. Such transactions don't start in pre-committed state anymore
because that hack caused some weird side effects.
Is there any real problem with it except unexpected numbers in stats?

--
WBR, SD.

[gkvi...@gmail.com]

i belive there is an never ending RORC transaction in my program. Should i use an other isolation level than read commited?

According to my understanding, shouldn't OTI catch up with the other values again after the program has been terminated?

[Mark Rotteveel]

On 14-11-2022 16:36, gkvi...@gmail.com wrote:
> i belive there is an never ending RORC transaction in my program. Should
> i use an other isolation level than read commited?

No, because then you would never see any changes since the start of that
transaction. You should consider no longer using a never-ending
read-only transaction, or you need to continue using ReadConsistency = 0
in firebird.conf (or in databases.conf for databases where never-ending
read-only transactions are used).

See also the Firebird 4.0 release notes:

-
https://www.firebirdsql.org/file/documentation/release_notes/html/en/4_0/rlsnotes40.html#rnfb40-engine-read-committed-read-only
-
https://www.firebirdsql.org/file/documentation/release_notes/html/en/4_0/rlsnotes40.html#rnfb40-compat-read-consistency

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

gkvi...@gmail.com wrote 14.11.2022 16:36:
> i belive there is an never ending RORC transaction in my program. Should i use
> an other isolation level than read commited?

Transaction isolation level is determined by business logic of tour
application. You must end any transaction as soon as it is not needed. For
Delphi with its datasets it is better to have separate transactions for each
dataset than one common, but again it is up to application logic.

--
WBR, SD.

[Vlad Khorsun]

According to my understanding, shouldn't OTI catch up with the other values again after the program has been terminated?

 

  There is no "OTI" term.

  There is OIT (Oldest [Interesting] Transaction) marker, but you speak here about OST (Oldest Snapshot

Transaction) marker, I suppose.

  Note, transaction numbers are re-evaluated at transaction start, so it is possible that "final refresh" not

happens to be visible after the only connection gone. One need to start new transaction to see updated

markers. Also, note, that OST (and OAT) markers makes no sence when there is no connections to the

database.

  About stuck OST, see my answer to the SD message soon.

Regards,

Vlad

[Vlad Khorsun]

> is this a normal behavior of the FB4?

If your application runs a never-ending RORC transaction then yes, it is
normal behavior.

  First, I must note that there is no "OTI" term. I suppose the author tald about stuck OST (not OIT

as one can think). And, yes, endless RCRC transaction will hold OST value and it is recommended

to do hard committ from time to time for long running RC RO transaction.
This recommendation is not new, btw, it was exists long before FB4 (but by different reasons).

 

Such transactions don't start in pre-committed state anymore
because that hack caused some weird side effects.

  This is not true, you refers to the bug at early documentation. It is very easy to check that RCRC RO

transaction is committed on start as any other RC RO transaction. And this have no relation with

original question about stuck OST, nor directly related with OIT movement.

 

Is there any real problem with it except unexpected numbers in stats?

 

  Good question :)

Regards,

Vlad

[gkvi...@gmail.com]

Hi all, thank you all for all the input and tips.

No I don't really have a problem, just using the values to see if I have a problem somewhere with a "hanging" transaction in my program. That's why I was wondering about the different behavior from FB3 to FB4.

I was not aware of the RORC transactions.

So thanks again for your support

Gregor