openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey (JIRA)" <>
Subject [jira] Commented: (OPENJPA-219) Reflection: negative caching would be beneficial in redeployment scenarios
Date Tue, 24 Apr 2007 00:23:15 GMT


Patrick Linskey commented on OPENJPA-219:

I agree about the mem leak problem in the patch that I created; hence my comments in the original
post about using weak references. There are a number of ways that you could solve this caching
problem, such as making all / part of Reflection non-static and setting up per-Configuration
caches, or using weak references in the cache, or even (and probably least attractively) creating
undeploy APIs.

Abe said: 
> If we're going to cache, I don't see why we wouldn't cache the declared 
> fields/methods rather than the nonexistent ones. It would be a simple
> matter of keeping a Class->Set cache, where the Set is the names of 
> the fields/methods returned by Class.getDeclaredFields/Methods(). 
> Then we'd have both a positive (set.contains(x)) and negative 
> (!set.contains(x)) cache.

As I mentioned in the original description, the bug here is that negative lookups are slow
because of the exception creation. I see no reason to add extra caching if we don't know if
we need it, although Bret's numbers potentially indicate that there is a benefit to positive
caching. I have no problem with having a positive cache, but I think that we should only include
it if it's going to help, since otherwise it'll just be one more thing contributing to memory

> Reflection: negative caching would be beneficial in redeployment scenarios
> --------------------------------------------------------------------------
>                 Key: OPENJPA-219
>                 URL:
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 0.9.0, 0.9.6, 0.9.7
>            Reporter: Patrick Linskey
>             Fix For: 0.9.8
>         Attachments: OPENJPA-219.patch
> In a variety of situations, OpenJPA searches class hierarchies for fields. These searches
invoke Class.getDeclaredField() in order to find non-public fields. This method throws an
exception when it fails to find the specified field, and the exception creation is, as ever,
> It would be useful to create a static (and thus per-classloader) Map<WeakReference<Class>,Collection<String>>
of fields known not to be available in a given class.
> It may also be beneficial to maintain a cache of which fields *are* present in a given
class, but this issue is being filed as a result of a demonstrated performance hit during
deployment due to the lack of a negative cache. If we obtain quantitative data indicating
that a positive cache would be useful, we might want to implement such a thing at that time.
> Trace 3 (2115 occurances): [excepti][00090] java/lang/NoSuchFieldException: domainName
>      at java/lang/Class.getDeclaredField(Ljava/lang/String;I)Ljava/lang/reflect/Field;(Unknown
>      at org/apache/openjpa/enhance/Reflection.findField(Ljava/lang/Class;Ljava/lang/String;Z)Ljava/lang/reflect/Field;(
>      at org/apache/openjpa/util/ApplicationIds.toPKValues(Ljava/lang/Object;Lorg/apache/openjpa/meta/ClassMetaData;)[Ljava/lang/Object;
> (

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message