openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Abe White (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-219) Reflection: negative caching would be beneficial in redeployment scenarios
Date Mon, 23 Apr 2007 20:01:15 GMT

    [ 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.


Mime
View raw message