[hibernate-issues] [Hibernate-JIRA] Commented: (HV-479) Implement an eviction strategy for BeanMetaDataCache
[
http://opensource.atlassian.com/projects/hibernate/browse/HV-479?page=com...
]
Kevin Pollet commented on HV-479:
---------------------------------
IMO, a concurrent map is better for a cache. I'm also wondering if it will work as
expected because the cached meta-data holds a reference to the key. Maybe using a
{{WeakReference}} will work but I'm not sure. I think we need further investigations.
In the WeakHashMap javadoc:
{quote}
The value objects in a WeakHashMap are held by ordinary strong references. Thus care
should be taken to ensure that value objects do not strongly refer to their own keys,
either directly or indirectly, since that will prevent the keys from being discarded
{quote}
BTW, is this the better strategy? Why not use an other strategy like LRU or LFU?
If we use another strategy do we allow the user to configure it (Configuration object
and/or property) or use it's own implementation?
Implement an eviction strategy for BeanMetaDataCache
----------------------------------------------------
Key: HV-479
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-479
Project: Hibernate Validator
Issue Type: Improvement
Components: engine
Reporter: Gunnar Morling
Fix For: 4.3.0.next
In {{BeanMetaDataCache}} we have a map from {{Class}} to {{BeanMetaDataImpl}}. Currently
there is no eviction strategy for this cache meaning entries will never be removed once
they were added to the cache and the {{ValidatorFactoryImpl}} holding the cache exists.
In particular this means that the concerned class objects never can be garbage-collected.
This might cause problems in long-running applications (especially as there is typically
one long-living {{ValidatorFactory}} instance per application). Maybe {{WeakHashMap}} or
similar might be useful here.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira