[Hibernate-JIRA] Created: (HHH-2316) org.hibernate.cache.CacheKey.equals() can cause PropertyAccessException to be thrown
7:20 a.m.
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
Type: Bug
Components: core
Versions: 3.2.1
Environment: Windows XP / Sybase 12.5 / Java 1.5.0_09 / ehcache 1.2.4
Reporter: Joel Caplin
Priority: Critical
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
7:08 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2316) org.hibernate.cache.CacheKey.equals() can cause PropertyAccessException to be thrown
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2316?page=c...
]
Joel Caplin commented on HHH-2316:
----------------------------------
To clarify a few points from above:
1) I'm not calling type.isEqual() myself - was referring to when equals() calls it.
2) The Type-implementing class which causes this exception to be thrown is ComponentType:
the "x" and "y" arguments are of different types
3) Only future calls which touch the same cache regions yield a PropertyAccessException -
not *all* hibernate calls, as I alluded to above.
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
Type: Bug
Components: core
Versions: 3.2.1
Environment: Windows XP / Sybase 12.5 / Java 1.5.0_09 / ehcache 1.2.4
Reporter: Joel Caplin
Priority: Critical
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
8:34 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2316) org.hibernate.cache.CacheKey.equals() can cause PropertyAccessException to be thrown
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2316?page=c...
]
Jifeng Liu commented on HHH-2316:
---------------------------------
I encountered the same bug in CacheKey class. When I have 2 Entities with composite
primary key and these 2 Entities are cached in same second-level cache region, this bug
happens.
I also found similar topic in Hibernate Forum:
http://forum.hibernate.org/viewtopic.php?t=962840&highlight=cachekey
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
Priority: Critical
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:31 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2316) org.hibernate.cache.CacheKey.equals() can cause PropertyAccessException to be thrown
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2316?page=c...
]
Max Rydahl Andersen commented on HHH-2316:
------------------------------------------
Your fix sounds reasonable, but we need a testcase to verify it actually fix the issue.
thanks.
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
Priority: Critical
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:46 p.m.
New subject: [Hibernate-JIRA] Updated: (HHH-2316) org.hibernate.cache.CacheKey.equals() can cause PropertyAccessException to be thrown
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2316?page=c...
]
Jifeng Liu updated HHH-2316:
----------------------------
Attachment: cacheTest.zip
I created a test case in the attached zip file. The exception's stack trace is:
org.hibernate.PropertyAccessException: IllegalArgumentException occurred calling getter of
org.hibernate.test.annotations.cidcache.OrderLinePk.firstname
at
org.hibernate.property.BasicPropertyAccessor$BasicGetter.get(BasicPropertyAccessor.java:171)
at
org.hibernate.tuple.component.AbstractComponentTuplizer.getPropertyValue(AbstractComponentTuplizer.java:64)
at
org.hibernate.tuple.component.AbstractComponentTuplizer.getPropertyValues(AbstractComponentTuplizer.java:70)
at
org.hibernate.tuple.component.PojoComponentTuplizer.getPropertyValues(PojoComponentTuplizer.java:83)
at org.hibernate.type.ComponentType.getPropertyValues(ComponentType.java:353)
at org.hibernate.type.ComponentType.isEqual(ComponentType.java:123)
at org.hibernate.cache.CacheKey.equals(CacheKey.java:51)
at java.util.HashMap.eq(HashMap.java:299)
at java.util.HashMap.getEntry(HashMap.java:398)
at java.util.LinkedHashMap.get(LinkedHashMap.java:273)
at net.sf.ehcache.store.MemoryStore.get(MemoryStore.java:130)
at net.sf.ehcache.Cache.searchInMemoryStore(Cache.java:819)
at net.sf.ehcache.Cache.get(Cache.java:654)
at org.hibernate.cache.EhCache.get(EhCache.java:74)
at org.hibernate.cache.ReadWriteCache.afterInsert(ReadWriteCache.java:289)
at
org.hibernate.action.EntityInsertAction.afterTransactionCompletion(EntityInsertAction.java:169)
at org.hibernate.engine.ActionQueue.afterTransactionCompletion(ActionQueue.java:170)
at org.hibernate.impl.SessionImpl.afterTransactionCompletion(SessionImpl.java:424)
at org.hibernate.jdbc.JDBCContext.afterTransactionCompletion(JDBCContext.java:225)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:119)
at
org.hibernate.test.annotations.cidcache.CompositeIdCacheTest.testCache(CompositeIdCacheTest.java:32)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at org.hibernate.test.annotations.TestCase.runTest(TestCase.java:68)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:297)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:672)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:567)
Caused by: java.lang.IllegalArgumentException: object is not an instance of declaring
class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.hibernate.property.BasicPropertyAccessor$BasicGetter.get(BasicPropertyAccessor.java:145)
... 36 more
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
Priority: Critical
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:23 p.m.
New subject: [Hibernate-JIRA] Updated: (HHH-2316) org.hibernate.cache.CacheKey.equals() can cause PropertyAccessException to be thrown
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2316?page=c...
]
Steve Ebersole updated HHH-2316:
--------------------------------
Priority: Major (was: Critical)
Assignee: Steve Ebersole
Fix Version/s: 3.2.4
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:45 p.m.
New subject: [Hibernate-JIRA] Updated: (HHH-2316) org.hibernate.cache.CacheKey.equals() can cause PropertyAccessException to be thrown
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2316?page=c...
]
Steve Ebersole updated HHH-2316:
--------------------------------
Fix Version/s: (was: 3.2.4)
Are you really putting different entity data into the same cache region? That is clearly
not a tested scenario, nor would it be recommended. However, it is allowable.
Joel, is that the underlying reason for your issues as well? Are you pushing cached data
from separate entities into the same cache region?
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
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:20 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2316) org.hibernate.cache.CacheKey.equals() can cause PropertyAccessException to be thrown
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2316?page=c...
]
Joel Caplin commented on HHH-2316:
----------------------------------
Sorry - it's been a long time since I looked at this so I'll take baby steps:
- We have an entity "LocalKey"
- Lots of other entities in our model contain associated sets of these local keys
- The set collection in the other entities is constrained by a where clause (which is
usually something like "where local_key_type='ENTITY_NAME')
- We cache LocalKey instances themselves in a region called "LocalKeys". So in
our LocalKey.hbm.xml we have a <cache usage="read-only"
region="LocalKeys"> type expression underneath the <class> element
- We cache the set associations (i.e. Entity1 -|--<- LocalKey, Entity2 -|--<-
LocalKey) in the same region. So in our XXXEntity.hbm.xml we have a similar cache
expression as above, except underneath the <set> element
So I suppose that yes, we are pushing cached data from separate entities (the LocalKeys
themselves *and* the associations) into the same cache region.
HTH
Joel
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
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:30 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2316) org.hibernate.cache.CacheKey.equals() can cause PropertyAccessException to be thrown
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2316?page=c...
]
Steve Ebersole commented on HHH-2316:
-------------------------------------
Well the simple workaround is to cache them in separate regions. This is what Hibernate
does normally. I'll fix this issue as you suggested because what you said makes
sense. However, you should note that I will not guarentee that what you are trying
(sharing cache regions) will work in all cases.
What was the reasoning for sharing regions anyway?
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
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:37 p.m.
New subject: [Hibernate-JIRA] Resolved: (HHH-2316) org.hibernate.cache.CacheKey.equals() can cause PropertyAccessException to be thrown
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2316?page=c...
]
Steve Ebersole resolved HHH-2316.
---------------------------------
Resolution: Fixed
Fix Version/s: 3.2.4
trunk / 3.2
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:42 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2316) org.hibernate.cache.CacheKey.equals() can cause PropertyAccessException to be thrown
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2316?page=c...
]
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6264
days inactive
6405
days old
hibernate-issues@lists.jboss.org
10 comments
4 participants
participants (4)
-
Jifeng Liu (JIRA) -
Joel Caplin (JIRA)
-
Max Rydahl Andersen (JIRA)
-
Steve Ebersole (JIRA)