openjpa-dev mailing list archives

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


Abe White commented on OPENJPA-219:

1. Yes, clearly we'd use our org.apache.openjpa.lib.util.concurrent. ConcurrentReferenceHashMap
with weak keys to hold the Classes.

2. We have no evidence that a positive cache would consume any more memory than a negative
cache in this case.  A positive cache's entry size for a given class is limited by the number
of fields/methods in that class.  A negative cache's entry size is limited only by how many
nonexistent field/method names we look for.  The negative cache will probably be smaller in
this case except in deep inheritance hierarchies because I don't think we look for field or
method names outside the inheritance hierarchy, but (a) I'm not sure of that and (b) there's
no guarantee that will always be the case.

3. You know, another way to approach this would be not to cache at all, and just iterate over
getDeclaredFields/Methods() looking for a match rather than using the singular getDeclaredField/Method()
that throws an exception.  If that gives decent performance, we wouldn't have to worry about
the memory consumption and complication of caching.  Bret, do you think you could try that
out and see how it does?

> 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