I'd like to use the following post as a reference: http://72.5.124.102/thread.jspa?threadID=788137&messageID=4479784
"The DLL will remain loaded between calls, so if you use a global variable to store the connection then it should be ok. "
Of course this makes logical sense. However, JNI doesn't have a handle from my understanding... JNI looks like this:
private native void nativeMethodInvoke();
static {
System.load(path+dllName) // many alts to this, but yea.
}
// somewhere in main thread....
SelfClass varRefToSelf=new SelfClass();
// where SelfClass is the current class running.
// This doesn't make sense to me, considering usage of 'this' - so if anyone can explain that, I would greatly appreciate it.
varRefToSelf.nativeMethodInvoke();
So.... am I supposed to keep a global reference within my class, to itself?!?
The actual problem is that I'm using a server-side language to invoke Java, and thus C++ via JNI. However, the server-side language is creating a new instance of the JAR upon each invocation. So my plan was to pass a reference to the module handle, and somehow manage to get that back to server-side language, and then furthermore back to Java JNI. Am thinking about moving to a servlet instead, since this doesn't appear to be possible - as unfortunate as that is.
Would SingleThreadModel work in this case? Or should I have C++ thread itself, so when Java makes a call, I can let C++ handle data by forwarding to correct module in memory? Assuming the above mentioned post is accurate, then the DLL, when loaded by Java, will stay in memory until unloaded. If the jvm is exiting after each server-side invocation, I must assume multiple instances of the dll are being created. So, am thinking this prospect will work... servlets aside...
Any help is appreciated. I clearly do not understand JNI as well as I should.
*Edit:
I have already tried this, and found that C++ DLL's thread is definitely active in memory post-jvm exit. The DLL also appears to be loaded multiple times, as the data I'm dealing with appears to be unique, in that it's not "stepping into itself" and overwriting pointers, or anything.
Am I going to have to create an instance of my class, via itself, to launch itself in the jvm manually - to keep the reference to dll in memory?
Although that statement sounds terribly redundant... I believe it's accurate...
1.) Create instance of class that's called by server-side, launch it under new jvm
2.) Have orig class return to server-side as normal, and forward any new requests to the jvm-launched "self"; based on detection of class/jvm in memory...
For being cross-platform "magical", Java sure makes it difficult to perform pretty basic tasks....