> That's the right answer, but it's a little trickier than that. To keep
> from killing other running procedures, you need to keep several versions
> of a class (or, more likely, classes) and have a mechanism to purge the
> old versions when they are no longer in use.

It's not currently supported, but it should be possible to use a
notification pattern which notifies the controller after procedure
completes the execution. Thanks for a tip!

>> What exactly do you mean? In the database the normal GRANTs apply. If
>> you ask, whether it is possible to use Java code "implemented" for
>> another database? Yes, but that was also not the target for that
>> release. It is possible to extend the code to check the manifest
>> embedded in the JAR file, but it is also possible to load classes from
>> the database.
>>
> Loading base classes from a jar file and application classes from either
> the file system (development) or the database (production) is the way to go.

Yup, the classloader hierarchy is the right answer.

Roman