|Subject||Re: [Firebird-Architect] RFC: External Engine API|
>> Otherwise you have to require each procedure written inC++ has the same issue - as you wrote, either you use some global
>> 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?).
> I do not understand how this is any different to C++/Java?
variables or you pass the handles explicitly. If you use global
variables (TLS, for example) and do not want to use TLS in the engine
(or that DLL that exports the ISC API for ESPs), either application code
or DB access components must explicitly know where and how to get them.
In Java I am required to write a proxy which would translate ESP call
into Java. I can pass the handles into a generic method
"callJavaFunction" and store them in TLS. Then when Java SP makes call
to the engine, it goes through my proxy anyway, so I am able to
intercept the call and return the required handle in JNI counterpart for
isc_attach_database or isc_start_transaction. In other words, I do not
need to change the Java SP code (two additional parameters in methods)
or the driver (make it know the TLS) to handle the callbacks.
> Either you build classes to carry the additional informationC++ - no, but there are really-really many "tricks" in Java that you
> between calls (available in Delphi/Object-Pascal or C++), or
> you use global variables (aka TLS), or you use additional
> parameters. I am not aware of any secret features in C++ or
> Java that offer any other solutions.
don't have in Delphi or C++. For example it is possible to inject byte
code into the user classes when they are loaded and intercept calls to
methods on the fly (aspect-oriented programming). I can generate classes
on the fly with the method signatures I need. And so on... And these are
more or less normal techniques in modern Java - just check what in O/R
mappers is used...
> IOW it seems to me that any solution you create for C++ or JavaAny solution for C++ is ok for Delphi. This does not apply to Java and I
> _could_ be adapted for Delphi.
think to .NET (managed).
> I think the thing would be toOh yes... Unfortunately they are silent for some reason...
> ask the library developers what they need/want - particularly
> in the case of Delphi where (I assume most) development takes
> place via an existing library rather than directly to the API.