CODEWITHSUNDEEP
dlljava-native-interfacereload
Debojit Kundu
Debojit Kundu

Reputation: 131

Unloading and reloading dll without restarting the jvm

I am working with a java program where I need to call a native library in order to call other dll that in turn would contact some Remote "Amadeus" (Airline related service) service. Problem statement: The jni dll creates a session every time it contacts the remote service and close the session after completion of its intended task. Its very similar to jdbc approach where no connection pooling is involved. Now it seems that the session is actually not being closed properly and at the server end it eventually results in max session exception and refusing any further connection requests. It seems there is some issue at the dll-remote service connectivity end, because from java code the connection is being properly closed by calling the native call. Workaround identified: Restarting the application fixes this issue because it forces all open connection getting closed. We don't have access to alter the dll for the time being, so we are thinking if we could have the same flavour of restarting the jvm without actually restarting the jvm but reconnecting (unloading and reloading) the dll. Here we think if we can disconnect the dll, all memory allocated to the dll would be cleared off, and hence would force to close/collect the open sessions at server end. Question: Can we really unload and then reload the dll without restarting the jvm?

Please help us.

Thanks in advance.

Krgds, Debojit

Upvotes: 3

Views: 1339

Answers (1)

Andrew Henle
Andrew Henle

Reputation: 1

You can unload it. It's probably not safe to do so, however.

Assuming you're running on a Windows platform, without knowing the details of the DLL, it's not possible to safely unload the library. Per the documentation for the FreeLibrary function:

Use caution when calling FreeLibrary with a handle returned by GetModuleHandle. The GetModuleHandle function does not increment a module's reference count, so passing this handle to FreeLibrary can cause a module to be unloaded prematurely.

Since you're not going to have direct access to the handle used to load the library nor all the references into the library, you can't know if all references to the library are no longer used.

Also, unloading the library may not solve your problem. Ending the entire process solves the problem because that causes everything that process uses to be released/closed (for the most part - there are always exceptions...). Simply unloading one library loaded into the address space doesn't do that. Unloading the library might do what you want - if the library is designed to work that way. Given that it's apparently not working properly when used normally, I'd say the odds of it working properly when used abnormally aren't very good - if unloading the library while it's being used doesn't cause even worse problems.

You need to actually solve the problem - not simply try things and see if they work.

Upvotes: 1

Related Questions