March 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-4436) Stackoverflow exception if Composite id has many to one relationship and fetchMode = EAGER

by Kirill Trofimov (JIRA)

Stackoverflow exception if Composite id has many to one relationship and fetchMode = EAGER ------------------------------------------------------------------------------------------ Key: HHH-4436 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4436 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.0.SP1 Environment: hibernate-core: 3.3.0.SP1, hibernate-annotations: 3.4.0.GA Reporter: Kirill Trofimov Attachments: hibernatetest.zip Stackoverflow occurred if composite id has many to one relationshipt. See unit test in attached file. -- 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

14 years, 5 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-4868) Upgrade to Javassist 3.11.GA

by Julien Kronegg (JIRA)

Upgrade to Javassist 3.11.GA ---------------------------- Key: HHH-4868 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4868 Project: Hibernate Core Issue Type: Improvement Affects Versions: 3.5.0-Beta-4, 3.3.2, 3.3.1 Reporter: Julien Kronegg Priority: Minor Hibernate 3.3.1 uses Javassist 3.4.GA (3.5 years old) Hibernate 3.3.2 uses Javassist 3.9.GA (1.5 years old) Hibernate 3.5.0 uses Javassist 3.9.GA (1.5 years old) -- 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

14 years, 5 months

4
7
0 / 0

[Hibernate-JIRA] Created: (HHH-4738) getSingleResult returning SQLException in DerbyDialect

by Samuel Halliday (JIRA)

getSingleResult returning SQLException in DerbyDialect ------------------------------------------------------ Key: HHH-4738 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4738 Project: Hibernate Core Issue Type: Bug Components: query-hql Affects Versions: 3.5.0-Beta-2 Environment: hibernate 3.5.0-0.2, Glassfish v3, Derby Reporter: Samuel Halliday I am encountering problems when issuing getSingleResult queries using the Glassfish v3 "hibernate 3.5.0-0.2". These queries work fine if I use hibernate 3.3.1.GA, or a PostgreSQL backend/dialect. Something between 3.3.1 and 3.5 has therefore introduced this bug. The queries are along the lines of [code] Query q = em.createQuery("SELECT COUNT(s) FROM MyTable s"); Long result = (Long) q.getSingleResult(); [/code] and [code] Query query = em.createQuery("SELECT s FROM MyTable s ORDER BY s.id"); query.setFirstResult(id); query.setMaxResults(1); MyTable random = (MyTable) query.getSingleResult(); [/code] The exception I am seeing is below, when used with (at least) the Java Derby DB. The message is "The column position '1' is out of range. The number of columns for this ResultSet is '0'." [code] Caused by: java.sql.SQLException: The column position '1' is out of range. The number of columns for this ResultSet is '0'. at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source) at org.apache.derby.client.am.ColumnMetaData.getColumnType(Unknown Source) at org.apache.derby.client.am.PreparedStatement.setInt(Unknown Source) at org.hibernate.loader.Loader.bindLimitParameters(Loader.java:1669) at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1594) at org.hibernate.loader.Loader.doQuery(Loader.java:694) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:257) at org.hibernate.loader.Loader.doList(Loader.java:2232) ... 42 more Caused by: org.apache.derby.client.am.SqlException: The column position '1' is out of range. The number of columns for this ResultSet is '0'. at org.apache.derby.client.am.ColumnMetaData.checkForValidColumnIndex(Unknown Source) ... 49 more [/code] -- 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

14 years, 5 months

4
7
0 / 0

[Hibernate-JIRA] Created: (HHH-2645) Synchronization bottleneck in EntityModeToTuplizerMapping

by Erik Bergersjö (JIRA)

Synchronization bottleneck in EntityModeToTuplizerMapping --------------------------------------------------------- Key: HHH-2645 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2645 Project: Hibernate3 Issue Type: Patch Components: core Affects Versions: 3.2.4.sp1, 3.2.4, 3.2.3 Environment: Hibernate 3.2.3 (and later), Sun's JDK 1.4.2_12 (server VM) on SunOS 5.10, Oracle 10g R2 Reporter: Erik Bergersjö Priority: Minor We have had a major performance bottleneck in EntityModeToTuplizerMapping with Hibernate version 3.2.3 and the code for that class in 3.2.4sp1 is unchanged. We have found a solution that solves the issue and would like to get it into the real version. I submitted to the user forum first and was asked to create a JIRA issue. The problematic line is: private final Map tuplizers = Collections.synchronizedMap( new SequencedHashMap() ); We have changed it to (using util.concurrent): private final Map tuplizers = new EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap(); This change alone makes our use cases six times faster. The difference is that ConcurrentReaderHashMap handles concurrent readers much better, they don't have to wait for each other. The problem occurs when a high number of threads try to initialize sets (see mapping below). A thread dump showed a high number of threads waiting for the same monitor, see partial stack trace below. The code runs on Sun's JDK 1.4.2_12 (server VM) on SunOS 5.10 and the kernel spends a lot of time handling mutexes with the original implementation. That time disappears from the radar screen with the fixed version. Example mapping for set: [code] <set name="lines" lazy="true" inverse="true" cascade="all-delete-orphan"> <key> <column name="col1" not-null="true" /> <column name="col2" not-null="true" /> </key> <one-to-many class="LineClass" /> </set> [/code] Stack trace (partial): "Thread-108" prio=5 tid=0x05852e90 nid=0x103 waiting for monitor entry [0x3ed7e000..0x3ed7fc28] at java.util.Collections$SynchronizedMap.get(Collections.java:1942) - waiting to lock <0x89d30788> (a java.util.Collections$SynchronizedMap) at org.hibernate.tuple.EntityModeToTuplizerMapping.getTuplizerOrNull(EntityModeToTuplizerMapping.java:53) at org.hibernate.tuple.EntityModeToTuplizerMapping.getTuplizer(EntityModeToTuplizerMapping.java:66) at org.hibernate.type.ComponentType.getPropertyValues(ComponentType.java:353) at org.hibernate.type.ComponentType.isEqual(ComponentType.java:141) at org.hibernate.engine.CollectionKey.equals(CollectionKey.java:50) at java.util.HashMap.eq(HashMap.java:274) at java.util.HashMap.get(HashMap.java:323) at org.hibernate.engine.loading.CollectionLoadContext.getLocalLoadingCollectionEntry(CollectionLoadContext.java:163) at org.hibernate.engine.loading.CollectionLoadContext.locateLoadingCollectionEntry(CollectionLoadContext.java:150) at org.hibernate.engine.loading.CollectionLoadContext.getLoadingCollection(CollectionLoadContext.java:92) at org.hibernate.loader.Loader.readCollectionElement(Loader.java:1003) at org.hibernate.loader.Loader.readCollectionElements(Loader.java:646) at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:591) at org.hibernate.loader.Loader.doQuery(Loader.java:701) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236) at org.hibernate.loader.Loader.loadCollection(Loader.java:1994) at org.hibernate.loader.collection.CollectionLoader.initialize(CollectionLoader.java:36) at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:565) at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:60) at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1716) at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:344) at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86) at org.hibernate.collection.PersistentSet.iterator(PersistentSet.java:163) -- 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

14 years, 5 months

8
28
0 / 0

[Hibernate-JIRA] Created: (HHH-3050) Convert usage of Hibernate's FastHashMap to ConcurrentHashMap (Java 1.5)

by Gail Badner (JIRA)

Convert usage of Hibernate's FastHashMap to ConcurrentHashMap (Java 1.5) ------------------------------------------------------------------------ Key: HHH-3050 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3050 Project: Hibernate3 Issue Type: Improvement Reporter: Gail Badner Assignee: Gail Badner Fix For: 3.3 The performance test attached to HHH-2645 shows that java.util.concurrent.ConcurrentHashMap (introduced in Java 1.5) performs nearly as well as org.hibernate.util.FastHashMap. Hibernate needs to move to Java 1.5 before this can be done. As noted in HHH-2645, it might be worthwhile to convert usages of FastHashMap to ConcurrentHashMap so that FastHashMap does not need to be maintained. -- 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

14 years, 5 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-5005) Column name not prefixed with table name alias

by Jeremy Hindmarsh (JIRA)

Column name not prefixed with table name alias ---------------------------------------------- Key: HHH-5005 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5005 Project: Hibernate Core Issue Type: Bug Components: annotations Affects Versions: 3.5.0-CR-2 Environment: Hibernate 3.5 CR2, Oracle 10g Reporter: Jeremy Hindmarsh If a column name annotation contains a full stop, the column name is not prefixed with the table name alias. Some of our database tables contain Oracle spatial data. One in particular has two columns for longitude and latitude, GEOM.SDO_POINT.X and GEOM.SDO_POINT.Y The problem is that the table alias is not added to the column name due to isIdentifier method in the Template class. This method returns false because the column name contains full stops. This means the renderWhereStringTemplate method doesn't prefix the column name with the table alias placeholder. Fortunately for now I can use the following column definition, in order to get the table alias added. @Column(name = "$PlaceHolder$.GEOM.SDO_POINT.X") -- 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

14 years, 5 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HHH-4786) SerializableType + custom Serializable class + L2 cache causes problems

by Steve Ebersole (JIRA)

SerializableType + custom Serializable class + L2 cache causes problems ----------------------------------------------------------------------- Key: HHH-4786 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4786 Project: Hibernate Core Issue Type: Bug Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.5.0-Beta-3 The changes done for HHH-2990 cause an issue when users map non-JDK Serializable classes using SerializableType in combination with attempting to cache those values into second level cache. SerializableType reports the classloader to use for deserialization as the classloader of java.io.Serializable (which is generally null indicating the "bootstrap class loader"). However that classloader will (generally) not have visibility into the classloader needed to see these non-JDK classes. -- 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

14 years, 5 months

2
3
0 / 0

[Hibernate-JIRA] Created: (ANN-820) TypeDef does not work when used on @Embeddable or @MappedSuperClass classes.

by Ted Bergeron (JIRA)

TypeDef does not work when used on @Embeddable or @MappedSuperClass classes. ---------------------------------------------------------------------------- Key: ANN-820 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-820 Project: Hibernate Annotations Issue Type: Bug Components: binder Affects Versions: 3.4.0.GA Environment: Oracle 11, hibernate 3.4.0 GA Reporter: Ted Bergeron @TypeDefs({ @TypeDef( name = "status", typeClass = EnumUserType.class, parameters = {@Parameter(name = "enumClass", value = "com.acme.common.model.Status")} ) }) I declare various @TypeDefs such as this. They all work fine when used in @Entity classes. When used in a @MappedSuperclass, or an @Embeddable, they fail. I see from the docs that these are global and double checked that I do not have any duplicate @TypeDef definitions. -- 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

14 years, 5 months

5
9
0 / 0

[Hibernate-JIRA] Created: (HV-298) Add a section on using the annotation processor to the HV reference guide

by Gunnar Morling (JIRA)

Add a section on using the annotation processor to the HV reference guide ------------------------------------------------------------------------- Key: HV-298 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-298 Project: Hibernate Validator Issue Type: Improvement Components: documentation Affects Versions: 4.1.0-Beta-1 Reporter: Gunnar Morling Assignee: Hardy Ferentschik A section describing the annotation processor should be added to the HV reference guide. It should cover the following: * Features of the AP * Options that control the AP's behavior * Integrating the AP into the build process: * Plain javac * Maven/Ant * IDE builds -- 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

14 years, 6 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-168) Add the ability to disable automatic indexing both on a per index level and programmatically

by Eric Winter (JIRA)

Add the ability to disable automatic indexing both on a per index level and programmatically -------------------------------------------------------------------------------------------- Key: HSEARCH-168 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-168 Project: Hibernate Search Issue Type: New Feature Components: engine Reporter: Eric Winter Priority: Minor It is very resticitive in an application that has multiple indexes to only allow the disabling of automatic indexing on an application wide level (or at least SessionFactory wide...). I can see it being very useful to have auto indexing on a per index basis. Also, it would be nice to be able to turn auto indexing off and on programmatically using something like Search.setAutoIndexing("myIndex", false); //per index and Search.setAutoIndexing(false); //global -- 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

14 years, 6 months

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues March 2010