[
https://issues.apache.org/jira/browse/OPENJPA-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491038
]
Abe White commented on OPENJPA-219:
-----------------------------------
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.
I'd also like to see some explicit control over whether requests to find a
field/method cause cache additions. It might be that we always want caching
now, but it's such a general class that I can imagine naïvely using the
Reflection class's helper methods on one-off random field/method requests in
the future without remembering the memory consequences. If all use results in
caching, that could be bad. So I'd like us to either add separate caching
methods or a boolean parameter to the existing methods. And either way, we
need to revisit our current use of Reflection to decide which version to use in
the current code.
> 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.
