On 11/5/07, Stefan Zoerner <stefan@labeo.de> wrote:
Hi all!

Hi Stefan,

The current interface StoredProcEngineConfig from

basically looks like this:


interface StoredProcEngineConfig
      * Returns the type of the associated {@link StoredProcEngine}.
     Class<? extends StoredProcEngine> getStoredProcEngineType();

      * Returns the unique language identifier of the {@link
     String getStoredProcLangId();


The interface StoredProcEngine has only one SPLangId, as well.

This makes it hard to provide a StoredProcEngine implementation for more
than one language. I have started a BsfStoredProcEngine, and ran into
two problems:

* My StoredProcEngine should be able to support several scripting
languages, but I can only return one of them as SPLangId

I am not sure that you need to specify each language supported by BSF with a distinct Id. I think only an Id such as "BSF" is enough. Because from the point of view of the ExecutionEngine it won't matter which specific language is being used as the BSF provider. All of those providers can support Java objects passed as parameters. The BSF abstraction provides other useful tools to handle all the languages with a single API, as far as I remember.

I had developed a prototype implementation for Javax Scripting API languages here:


It's really not tested well but it may give some idea.

* The only way to create my class currently is the default constructor.
Thus I am not able to use Spring to configure my StoredProcEngine

I would like to modify the interfaces in order to support
StoredProcEngines with more than one language, and to configure them
with properties.

As I said before feel free to modify any part of the SP subsystem. I did not make it very flexible because when I refactored the code the server configuration system was being refactored extensively. So I had left DI out temporarily.

Before I can propose concrete changed, I have a question (probably to Ersin)

The StoredProcEngine life cycle seems to presume that there is an
instance for each stored procedure. How often are the methods
* setSPUnitEntry
* invokeProcedure
presumed to be called?

They are invoked upon each SP call.

Currently, the implementation within StoredProcExecutionManager looks
like a new StoredProcEngine is created for each call. The methods will
be called one after the other. Is a StoredProcEngine supposed to be
stateful or stateless?

And they are stateful.

BTW I had faced also some other restrictions to be able to support SPs from both over the wire and from the core. So some of the difficulties about extending the system can be caused by such limitations.

Thanks in advance,

Thanks for working on this and sharing your thoughts Stefan.