Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 56710 invoked from network); 2 Apr 2010 14:26:34 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 2 Apr 2010 14:26:34 -0000 Received: (qmail 92599 invoked by uid 500); 2 Apr 2010 05:26:34 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 92558 invoked by uid 500); 2 Apr 2010 05:26:33 -0000 Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user-java@ibatis.apache.org Delivered-To: mailing list user-java@ibatis.apache.org Received: (qmail 92551 invoked by uid 99); 2 Apr 2010 05:26:33 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Apr 2010 05:26:33 +0000 X-ASF-Spam-Status: No, hits=2.9 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.221.189] (HELO mail-qy0-f189.google.com) (209.85.221.189) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Apr 2010 05:26:28 +0000 Received: by qyk27 with SMTP id 27so2086540qyk.23 for ; Thu, 01 Apr 2010 22:26:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.231.10 with HTTP; Thu, 1 Apr 2010 22:26:06 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Apr 2010 23:26:06 -0600 Received: by 10.229.38.147 with SMTP id b19mr2843163qce.102.1270185966735; Thu, 01 Apr 2010 22:26:06 -0700 (PDT) Message-ID: Subject: Re: ClassInfo.CLASS_INFO_MAP From: Derek Scherger To: user-java@ibatis.apache.org Content-Type: multipart/alternative; boundary=0016363b8be85b012904833a378d --0016363b8be85b012904833a378d Content-Type: text/plain; charset=UTF-8 On Thu, Apr 1, 2010 at 10:55 PM, Clinton Begin wrote: > This is a known issue. I agree that it would be nice to do something with > it. Ideas are welcome. The only one I have at the moment is to make > ClassInfo an instance and inject it into the SQL mapper configuration. I've > done similar things to eliminate static classes in the framework. A ClassInfo.release(ClassLoader) method that releases all cached information for classes loaded by the specified class loader might do it. Commons logging has something like this on LogFactory, although commons logging is probably not what you want to be using as a model for how to do this right ( http://articles.qos.ch/classloader.html). Commons logging also uses its own internal weak hash map implementation to avoid holding hard references to cached loggers. Using something similar might be a bit better, in that no explicit release is needed when the webapp context is destroyed. You can call ClassInfo.setCacheEnabled(false); to stop it from caching > classes. > How much of a performance penalty will this cause? I don't have any problems with the cache while the classloader is live but clearing it when the classloader dies would be good. ;) Cheers, Derek --0016363b8be85b012904833a378d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 1, 2010 at 10:55 PM, Clinton Begin <= span dir=3D"ltr"><clinton.beg= in@gmail.com> wrote:
This is a known issue. =C2=A0I agree that it would be nice to do something = with it. Ideas are welcome. =C2=A0 The only one I have at the moment is to = make ClassInfo an instance and inject it into the SQL mapper configuration.= =C2=A0I've done similar things to eliminate static classes in the fram= ework.=C2=A0

A ClassInfo.release(ClassLoader) method that releases a= ll cached information for classes loaded by the specified class loader migh= t do it. Commons logging has something like this on LogFactory, although co= mmons logging is probably not what you want to be using as a model for how = to do this right (http:= //articles.qos.ch/classloader.html). Commons logging also uses its own = internal weak hash map implementation to avoid holding hard references to c= ached loggers. Using something similar might be a bit better, in that no ex= plicit release is needed when the webapp context is destroyed.

You can call ClassInfo.= setCacheEnabled(false); to stop it from caching classes.

How much of a performance penalty will this cause? I do= n't have any problems with the cache while the classloader is live but = clearing it when the classloader dies would be good. ;)

Cheers,
Derek

--0016363b8be85b012904833a378d--