Subject | UDF replacement: native shared libraries vs. Java |
---|---|
Author | Jan Mikkelsen |
Post date | 2000-04-06T22:51:07Z |
Jim Starkey <jas@...> wrote:
on a running system. Other than a simple matter of programming, of course.
:-)
A new version of a DLL is loaded, new statements start using the new
functions. Once the statements which used the old functions are finished,
the old DLL is not needed, it can be unloaded.
There are file naming issues, but they can be handled operationally, or
using the new Windows 2000 conventions. It may also be that transactions
are better boundaries than statements. But I don't see any fundamental
reason why it can't be done with DLLs.
Jan Mikkelsen
janm@...
>I would very much like to see the current UDF mechanism phased outI can't really see why shared libraries (DLLs, whatever) can't be replaced
>in favor of Java. The sandbox model is attractive, but the (theoretical)
>ability to install or replace UDFs while the server is running would
>be absolutely wonderful. There are JVMs that handle dynamic class
>replacement, but no open source ones. The main problem is efficiency
>switching between C and Java without undue overhead. There are
>also thread and garbage collection issues, but given a suitably
>tame JVM...
on a running system. Other than a simple matter of programming, of course.
:-)
A new version of a DLL is loaded, new statements start using the new
functions. Once the statements which used the old functions are finished,
the old DLL is not needed, it can be unloaded.
There are file naming issues, but they can be handled operationally, or
using the new Windows 2000 conventions. It may also be that transactions
are better boundaries than statements. But I don't see any fundamental
reason why it can't be done with DLLs.
Jan Mikkelsen
janm@...