[
https://issues.apache.org/jira/browse/OPENJPA-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491310
]
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: https://issues.apache.org/jira/browse/OPENJPA-219
> 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, slow.
> 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
> Source)
> at
> org/apache/openjpa/enhance/Reflection.findField(Ljava/lang/Class;Ljava/lang/String;Z)Ljava/lang/reflect/Field;(Reflection.java:101)
> at
> org/apache/openjpa/util/ApplicationIds.toPKValues(Ljava/lang/Object;Lorg/apache/openjpa/meta/ClassMetaData;)[Ljava/lang/Object;
> (ApplicationIds.java:89)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
