I'm looking to do some cleanup of my custom database platform to prevent classloader leaks.
(EclipseLink as we use it is loaded by GlassFish; I need it to load the custom database platform in effect from our .ear file; if I do nothing else, this results in GlassFish holding a reference to the application's classloader thus preventing undeployment.)
To do this, Tom Ware kindly pointed me at the fact that in my (existing) SessionCustomizer I could easily add a SessionEventListener that {handwave handwave (and this is the question part)} listens for when the persistence units are undeployed and then roots around in the session and nulls out any references it finds to my database platform.
The rooting around and nulling out part consists of getting a Session from the SessionEvent, and setting its datasourceLogin property to null, as well as getting that DatasourceLogin first and setting its platform property to null. Obviously, this will result in a totally invalid state of affairs, but if the lifespans are all correct and EclipseLink is going down anyway it shouldn't matter. (Right? :-))
Fine; as these things go this doesn't look too bad. In my SessionCustomizer's customize(Session) method, I do something like this:
session.getEventManager().addEventListener(this); // my customizer is also a SessionEventAdapter overriding only one method
Then in my postReleaseClientSession(SessionEvent) method, I do:
final Login login = session.getLogin();
login.setPlatform(null);
session.setDatasourceLogin(null);
Both appear to be necessary to release the strong references to my JenzabarInformixPlatform class.
My question is: DO the lifespans line up? I want this method to be called only once, ever, viz. at persistence unit undeployment. Is that when postReleaseClientSession() will be called? Will this leave EclipseLink in some kind of bad state that will persist after redeployment (I hope not; I hope all these objects get blown away and reconstituted on the next persistence unit deployment)?
Thanks,
Best,
Laird
