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.

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

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)


Andrew

> If you are worried about creating lots of garbage we could cache it when the gds is assigned to the GDSHelper in the constructor and then just return the same proxy. The proxy has no state so we should be able to share if we can share the underlying gds.

Yes, that is an option. But what's the difference between creating the
GDS proxy and adding appropriate methods into GDSHelper? Also, proxy has
state, since the listeners registered on it are instances of
ManagedConnection and are bound to it.

Roman