>> So, from Java POV I'm ok with current API, but I see no solution for
>> Delphi without TLS.
>
> Why?

Assuming that your question targets Delphi case, the answer is:

Otherwise you have to require each procedure written in Delphi to take
two additional parameters - current DB handle and current TR handle, and
require Delphi code to pass them somehow into isc_XXX calls when
callback mechanism should be used (btw, will IBO or FIB+ allow such
things?).

If that is not acceptable requirement, then you have to store them
somewhere before passing the execution flow to the DB access components
to let them access those handles later. You need TLS there, since no
other ID is available except the "execution context". From my POV TLS
use in such case is reasonable.

If, however, the question was "why it is acceptable for Java" - well,
I'd prefer Vlad's approach where I just have to use different DPB/TPB
parameters. But I can also add some code to plugin and store handles in
TLS in Java code later. Java requires some proxy between Firebird and
JVM, so one can be relatively flexible there.

I could even say that we can have completely different API (not isc_XXX
entrypoints), but in this case you would need a volunteer to adapt
Jaybird for that API. There's some work to do, that's why I'm quite
sceptical about the discussion about non-ISC API.

Roman