> The issue is that there are a number of calls made directly to the gds implementation, unless you want to track down every single one of them and make sure you context correct for every single one of them, (I counted 24 last count with Eclipse and that does not count where its gotten, cached in a variable and then called ), I don't see an alternative. On top of that it is exposed through public methods in FBConnection so you don't know who else in the big wide world is playing with it and where. So we have to wrap it.

The GDS itself is not an issue here. It is stateless. The state is
stored in db, transaction and statement handles. So, whoever is playing
with GDS, nothing would happen unless it gets current db and transaction
handles.

That is the place where it becomes dangerous, the
AbstractConnection.getGDSHelper(), which provides access to the current
db handle, tr handle and so on. In theory one can change the transaction
state, close the connection and ManagedConnection won't notice. But this
is also possible by issuing for example "COMMIT" SQL statement -
transaction would be committed, but the driver won't know anything about it.

This is the place, where I would say - beware, do at your own risk.

As to the 24 calls you have counted, I think this has to be fixed - I
will move them to corresponding methods of the GDSHelper.

> As for listener state this is only every set in GDSHelp constructor and never again, so we should be okay.

Yup.

> This works its simple and actually has exactly the same issues as the GDS helper would have (including state where applicable), without the complications having to touch lots of code (at least 8 files)

Ok, now it seems that we understand each other - I do want to touch each
and every file to check the issue again. :)

Roman