tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Rudnicki <>
Subject Re: Classloader, JNI and "already loaded in another classloader"
Date Sun, 03 Jun 2001 10:54:00 GMT
> However, when running under a single Tomcat instance, I think
> that there is only 1 process (only one JVM in use).  There may be several
> threads, but only one process is in use.  Therefore, there is only 1 data
> segment that can be used.
> Or am I completely off base?

No, you are right, 1 instance of a DLL can only be created in a process.  If
as you describe, your DLL uses static/local variables, then you are stuck.
The library was designed for a single thread/process and you can't get
around it without reworking the library.


1) if you make multiple copies of the DLL with different names you may be
able to trick Windows into thinking they are actually different.  I'm fairly
sure it uses only the file name as the identifier, not the internal name.
This doesn't scale far but may get you some breathing room.

2) You could shim a switcher layer inbetween the DLL and callers.  If all
the data contained in the DLL was publically accessible, this might be easy.
Especially if it is a few structures, have a class that stores its own copy
of _all_ the data in the DLL, just place them before every call and remove
after every call.  This is similar to a context switch.  Without knowing the
details, I can't comment on whether this would be efficient.

3) If this legacy code is really important and you can't rework then you
must have the DLL in a separate process for every client.  The solution is a
wrapper process that you spawn from the servlet.  If the interface to the
DLL is fairly small, then a small Java program could "serve" the DLL using
some custom tcp.  The servlet could then communicate with the various
instances of the wrappers, each on a different port.  If the interface to
the DLL is larger, the you could consider wrapping it with a java class and
communicating through RMI.  Each servlet would spawn a java process with a
unique name to be used.  The wrapper process would create an instance of the
class, load the unique instance of the DLL and register the class under a
different name.

Lastly, if you get around your first problem, you have a bigger problem
-->  Your library is not thread safe.

The approach 2 above could address that also.


View raw message