[
https://issues.apache.org/jira/browse/IBATIS-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636625#action_12636625
]
Sylvain Laurent commented on IBATIS-540:
----------------------------------------
According to the comments in the original class, it was a way of passing around
some data without changing the prototypes of many methods.
There's no performance impact, anyway the ThreadLocal is setup before each
call. My patch just clean it up after the call
> Classloader memory leak because of ThreadLocal in ResultObjectFactoryUtil
> -------------------------------------------------------------------------
>
> Key: IBATIS-540
> URL: https://issues.apache.org/jira/browse/IBATIS-540
> Project: iBatis for Java
> Issue Type: Bug
> Components: SQL Maps
> Affects Versions: 2.3.3, 2.3.4
> Reporter: Sylvain Laurent
> Attachments: ibatis patch for classloader memleak.txt
>
>
> I'm using iBatis in a webapp with Spring and facing memory leaks upon
> redeployment oft he webapp.
> I tracked the leaks to ibatis, where the class ResultObjectFactoryUtil has a
> static ThreadLocal factorySettings
> The problem is that the value bound to a Thread through this ThreadLocal is
> never nullified, and since the "factorySettings" is a static variable, the
> ThreadLocal instance is reachable as long as the ClassLoader of the webapp is
> reachable. But since the FactorySettings instance is bound to the Thread
> through a strong reference (see the JDK implementation of ThreadLocal in
> ThreadLocalMap$Entry), the classloader is finally never collected...
> The solution is to always cleanup the ThreadLocal after usage (in
> SqlExecurtor)
> I attach a patch for iBatis 2.3.4 to this issue
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
