The application does not use "begin transaction and commit", so we let the
database commit automatically
after a write process, we read the table from another thread inside the app
or from another app inside the same OS session, and the data is not there.
Of course after a few seconds (or milliseconds) the data is available. Our
concern is that we have a sequence of code that assume whatever was written
5 lines above is already available for reading, but it is failing every so
often.

When did I last see that one? - ah yes, it was using an Access database to communicate from one process on one machine to another on another. You'd receive the sync event (via another channel), poll the database, and find that the new data wasn't actually there yet. Turned out that there was a half-second delay before data got flushed to disk, as an optimisation in case you were just about to write something else. (Which could, once you'd discovered what was going on, which might take a few days or weeks, be turned off.)

I don't however expect to see exactly the same problem with Firebird 3 ...

-- 
Tim Ward