[Hibernate-JIRA] Created: (HHH-3383) QueryKey is storing references to entities instead of identifiers
by Manuel Dominguez Sarmiento (JIRA)
QueryKey is storing references to entities instead of identifiers
-----------------------------------------------------------------
Key: HHH-3383
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3383
Project: Hibernate3
Issue Type: Improvement
Components: caching (L2)
Affects Versions: 3.3.0.CR1
Environment: ehcache 1.5.0b2
Reporter: Manuel Dominguez Sarmiento
Context: query caching
Hibernate is storing full entity references when building QueryKeys and the query has restrictions which reference entities. This happens either with Criteria or HQL queries.
Although this is not incorrect, when the referenced entities reference in turn "heavy" object graphs, this causes a very significant memory usage increase, since references to detached entities will remain in the cache. This is even more evident when using disk persistence with ehcache, since the full object graphs are serialized to disk.
This could be easily improved (correct me if I'm wrong) by storing ONLY entity identifiers in the QueryKey instead of full entities, since all the query really needs is the identifier property. The memory usage would decrease dramatically.
So far the workaround we've found is explicitly using restrictions that reference identifiers instead of properties in HQL queries, however this is not particularly elegant, and still leaves open the issue with Criteria queries. The same cannot be done without criteria.createCriteria() which generates an unnecessary join in most cases.
--
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
12 years, 8 months
[Hibernate-JIRA] Created: (METAGEN-56) Missing Singular attribute in import when merging attributes
by Martijn Blankestijn (JIRA)
Missing Singular attribute in import when merging attributes
------------------------------------------------------------
Key: METAGEN-56
URL: http://opensource.atlassian.com/projects/hibernate/browse/METAGEN-56
Project: Hibernate Metamodel Generator
Issue Type: Bug
Components: processor
Affects Versions: 1.1.1.Final
Environment: maven 3.0.2
Java: java version "1.6.0_22", Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Uname: Linux xxx 2.6.32-28-generic-pae #55-Ubuntu SMP Mon Jan 10 22:34:08 UTC 2011 i686 GNU/Linux
Reporter: Martijn Blankestijn
Assignee: Hardy Ferentschik
Attachments: 0001-Missing-SingularAttribute-import-with-mixed-xml-and-.patch, surefire-reports.tar.gz
I have failing testcases due to a missing import in the Generated ZeroCoordinates_.java.
My analysis:
The import "import javax.persistence.metamodel.SingularAttribute;" is not added to the file ZeroCoordinates_.java and will not compile due to this missing dependency.
It is a mixed configuration: so in the class JPAMetaModelEntityProcessor (line 237) the call is made to
metaEntity.mergeInMembers( alreadyExistingMetaEntity.getMembers() );
This basically means that the attributes of the already existing XML MetaEntity are placed in the attributesMap of the AnnotationMetaEntity.
public void mergeInMembers(Collection<MetaAttribute> attributes) {
for ( MetaAttribute attribute : attributes ) {
members.put( attribute.getPropertyName(), attribute );
}
}
This means that the AnnotationEmbeddable has a Context, but the members (the merged in Xml-attributes) have a different context. (Do not understand why there are two contexts, can you enlighten me?)
In the ClassWriter line 107
for ( MetaAttribute metaMember : members ) {
pw.println( " " + metaMember.getDeclarationString() );
}
the declaration string is printed. As the attributes are XMLMetaAttribute, their implementation of the getDeclarationString is
return "public static volatile " + hostingEntity.importType( getMetaType() )
+ "<" + hostingEntity.importType( hostingEntity.getQualifiedName() )
+ ", " + hostingEntity.importType( getTypeDeclaration() )
+ "> " + getPropertyName() + ";";
The hosting entity of the attribute is still the XmlMetaEmbeddable and when the importType is added, it is added to the wrong context (the context of the XMLMetaEmbeddable and NOT the AnnotationMetaEmbeddable).
Possible solution is to change the parent or create a new merged attribute (not ugly like I do below ;-))
MetaAttribute mergedAttribute = new XmlMetaSingleAttribute(this, attribute.getPropertyName(), attribute.getMetaType());
members.put( attribute.getPropertyName(), mergedAttribute );
This resolves the problem with the missing import, but if it is better to have a single context for both annotation and xml elements this might be a cleaner solution. Attached is the 'ugly' solution, but this leaves two failing testcases:
testAccessTypeForXmlConfiguredEmbeddables(org.hibernate.jpamodelgen.test.mixedmode.MixedConfigurationTest)
testMixedConfiguration(org.hibernate.jpamodelgen.test.mixedmode.MixedConfigurationTest)
The testMixedConfiguration could be a problem that the supplied solution is not yet the definitive answer ;-(:
=======================================================
Types do not match: Wrong meta model type expected:<class org.hibernate.jpamodelgen.test.mixedmode.RentalCompany> but was:<interface javax.persistence.metamodel.SingularAttribute>
org.testng.Assert.fail(Assert.java:84)
at org.testng.Assert.failNotEquals(Assert.java:438)
at org.testng.Assert.assertEquals(Assert.java:108)
at org.hibernate.jpamodelgen.test.util.TestUtil.assertAttributeTypeInMetaModelFor(TestUtil.java:176)
at org.hibernate.jpamodelgen.test.mixedmode.MixedConfigurationTest.testMixedConfiguration(MixedConfigurationTest.java:68)
30 lines not shown
=======================================================
The testAccessTypeForXmlConfiguredEmbbedables seems unreleated:
assertAbsenceOfFieldInMetamodelFor(
ZeroCoordinates.class,
"longitude",
"Field access should be used, but ZeroCoordinates does not define fields"
);
assertAbsenceOfFieldInMetamodelFor(
ZeroCoordinates.class,
"latitude",
"Field access should be used, but ZeroCoordinates does not define fields"
);
as I am not completely sure that the asserts are correct. The access type of embeddables dependends on the enclosing entity, so ain't it true that the field AND properties should be generated?
Regards,
Martijn
--
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
12 years, 8 months
[Hibernate-JIRA] Created: (HHH-5659) Problem using Hibernate3.6.0.Final with CLOB field in Oracle.
by Samuel Rettore (JIRA)
Problem using Hibernate3.6.0.Final with CLOB field in Oracle.
-------------------------------------------------------------
Key: HHH-5659
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5659
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.0
Environment: Hibernate 3.6.0.Final, Database Oracle10G on Linux X64, and JPA
Reporter: Samuel Rettore
Priority: Minor
When migrating my project that works well with Hibernate 3.5.6 End-to 3.6.0.Final the Clob field displays the following error
|java.lang.ClassCastException: $Proxy1119 cannot be cast to oracle.sql.CLOB
at oracle.jdbc.driver.OraclePreparedStatement.setClob(OraclePreparedStatement.java:7021)
at org.hibernate.type.descriptor.sql.ClobTypeDescriptor$1.doBind(ClobTypeDescriptor.java:60)
at org.hibernate.type.descriptor.sql.BasicBinder.bind(BasicBinder.java:89)
at org.hibernate.type.AbstractStandardBasicType.nullSafeSet(AbstractStandardBasicType.java:282)
at org.hibernate.type.AbstractStandardBasicType.nullSafeSet(AbstractStandardBasicType.java:277)
at org.hibernate.type.AbstractSingleColumnStandardBasicType.nullSafeSet(AbstractSingleColumnStandardBasicType.java:85)
at org.hibernate.persister.entity.AbstractEntityPersister.dehydrate(AbstractEntityPersister.java:2166)
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2412)
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2856)
at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:79)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:273)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:265)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:184)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1216)
at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:795)
at com.sun.enterprise.container.common.impl.EntityManagerWrapper.flush(EntityManagerWrapper.java:407)
---
This error appears only with CLOB field.
to get more information at their disposal.
Thanks
Rettore.
--
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
12 years, 8 months
[Hibernate-JIRA] Created: (HHH-5275) Criteria.setLockMode does not work correctly
by Björn Moritz (JIRA)
Criteria.setLockMode does not work correctly
--------------------------------------------
Key: HHH-5275
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.2
Environment: Hibernate 3.5.2, Oracle 10 (using org.hibernate.dialect.Oracle10gDialect
Reporter: Björn Moritz
Priority: Minor
Attachments: TestCase.zip
The LockMode set via Criteria.setLockMode does not generate a ' for update' SQL statement. In the org.hibernate.dialect.Dialect class only the LockOptions are used for determining a possible addition to the SQL statement if using pessimistic locking. This behaviour is different from Hibernate 3.1.3.
In the supplied TestCase two threads are reading the same database record; one of those threads should use pessimistic locking thereby blocking the other thread. But both threads can read the database record causing the test to fail.
--
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
12 years, 9 months
[Hibernate-JIRA] Created: (HHH-2763) (lazy) m:n relation + EventListener = AssertionFailure: collection [n-side] was not processed by flush()
by S.Schnabl (JIRA)
(lazy) m:n relation + EventListener = AssertionFailure: collection [n-side] was not processed by flush()
--------------------------------------------------------------------------------------------------------
Key: HHH-2763
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5, 3.2.4.sp1
Environment: Windows-XP, Jboss 4.2.1GA, Hibernate 3.2.4SP1, EJB3
Reporter: S.Schnabl
Priority: Critical
Attachments: Testcase.zip
For more details see the attached testcase. I'm sorry, but in the short of time i only got a testcase for jboss-server 4.2. Please deploy the server.ear from /release-directory and then call the /src/client/TestCaseClient.java.
[Summarized]
It seems, that touching a lazy (Persistent-)Collection of at least a m:n relation inside a Hibernate event-listener always raises this error:
org.hibernate.AssertionFailure: collection [n-side] was not processed by flush()
[Explanation]
I have two entities A. and B. Both having a m:n relation between each other. Furthermore there is an PostUpdateListener, which iterates onUpdate of entitiy through all properties of updated entity.
[Testcase]
Both entities are linked with eachother (m:n). If i now do a simple update of a property of entity A --> MyPostUpdateListener will be called, which iterates through every property of the updated entity. In case of this property was a collection (= lazy PersistentCollection of m:n relation), hibernate initializes the collection for further work. I can now run through all objects of the collection, but after all work is done in listener, I get the following exception from postFlush:
Caused by: org.hibernate.AssertionFailure: collection [com.qualitype.testcase.server.ejb.entity.EntityB.entitiesOfA] was not processed by flush()
at org.hibernate.engine.CollectionEntry.postFlush(CollectionEntry.java:205)
at org.hibernate.event.def.AbstractFlushingEventListener.postFlush(AbstractFlushingEventListener.java:333)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:28)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
at org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:515)
... 29 more
Attention: EntityB.entitiesOfA is the other-side collection of the m:n relation of the updated EntityA.
We are using hibernate-event listener system for auditing-purposes, so you should understand that touching every (element in the) collection is necessary for audit-purposes.
Seems for me like a serious bug. Need this fixed asap ...
--
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
12 years, 9 months