[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] Lifecycle of a client session?
|
Hi Laird,
Can you confirm that if you point at the InformixPlatform shipped as part of
EclipseLink you do not see the issue?
Our deployment keeps a cache of some of the metadata about various
persistence units. The process works by keeping a counter of the number of
EntityManagerFactories open for a particular persistence unit and when the last
one is closed, the cache is cleared. I am wondering if you are running into
some kind of a bug in that process.
If you set logging to FINEST, we output some information about these caches.
It would be interesting to look at what is happening to them. The log
messages are of this form:
- Begin predeploying Persistence Unit {0}; session {1}; state {2}; factoryCount {3}
- End predeploying Persistence Unit {0}; session {1}; state {2}; factoryCount {3}
- Begin deploying Persistence Unit {0}; session {1}; state {2}; factoryCount {3}
- End deploying Persistence Unit {0}; session {1}; state {2}; factoryCount {3}
- Begin undeploying Persistence Unit {0}; session {1}; state {2}; factoryCount {3}
- End undeploying Persistence Unit {0}; session {1}; state {2}; factoryCount {3}
Factory count is the interesting number. Does it ever get to 0?
-tom
On 12/06/2013 10:25 AM, Laird Nelson wrote:
On Wed, Jun 12, 2013 at 5:59 AM, Tom Ware <tom.ware@xxxxxxxxxx
<mailto:tom.ware@xxxxxxxxxx>> wrote:
What is it that leads you to believe the leak is related to your custom
database platform? Is the custom platform the same as the one that is now
checked into later versions of EclipseLink as Informix11Platform? If not,
how does it differ? Where is the reference to the GlassFish application
classloader held?
We took a heap dump immediately after doing a (GlassFish) asadmin undeploy and
found that EclipseLink (which as we use it is installed as part of GlassFish and
loaded by the GlassFish common classloader) was retaining a reference to
JenzabarInformixPlatform, which is present in a .jar file in our .ear file.
This platform was installed by a SessionCustomizer we wrote that (at a certain
point) does:
dataSourceLogin.setPlatformClassName("com.jenzabar....JenzabarInformixPlatform")
...which works fine. (The SessionCustomizer does not appear to be retained in
any way, which is good news.)
It made immediate sense to me: if the Login object hangs around longer than our
application does, then it retains a reference to the JenzabarInformixPlatform
and that would be enough to prevent the application from being undeployed.
Best,
Laird
--
http://about.me/lairdnelson
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
