]
Joel Caplin commented on HHH-2316:
----------------------------------
Partly (mostly) naive and partly because the previous solution (which existed outside the
realm of Hibernate) had this caching scheme in place already.
FWIW you might want to explicitly document that you don't recommened sharing caching
regions in the docs... I know at least one other project that does.
Thanks for your help
JC
org.hibernate.cache.CacheKey.equals() can cause
PropertyAccessException to be thrown
------------------------------------------------------------------------------------
Key: HHH-2316
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2316
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.1
Environment: Windows XP / Sybase 12.5 / Java 1.5.0_09 / ehcache 1.2.4
Reporter: Joel Caplin
Assignee: Steve Ebersole
Fix For: 3.2.4
Attachments: cacheTest.zip
org.hibernate.cache.CacheKey.equals() uses lazy evaluation in its return clause: it first
calls type.isEqual() and, if true, then calls entityOrRoleName.equals().
I am having difficulty reproducing this bug in the form of a test case owing to the
complexity of our model and the large amount of data in question-- however, in certain
circumstances, where the entityOrRoleName's are NOT equal, calling type.isEqual()
yields a PropertyAccessException.
When this bug manifests itself (a PropertyAccessException is thrown), it causes ALL
future Hibernate requests to throw a similar exception, thus rendering our service
unusable.
This is fixed when the lazy evaluation is done the other way around: call
entityOrRoleName.equals() prior to type.isEqual() - cheap string comparision vs an
expensive call which has a large call tree under it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: