August 2007 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2190) JDBCTransaction.isActive() should report false if jdbcContext.connection().isClosed()

by Jeffrey Bennett (JIRA)

JDBCTransaction.isActive() should report false if jdbcContext.connection().isClosed() ------------------------------------------------------------------------------------- Key: HHH-2190 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2190 Project: Hibernate3 Type: Bug Components: core Reporter: Jeffrey Bennett In error-handling routines, I use Transaction.isActive() to determine if it is 'safe' to perform Transaction.rollback(). If the Session has previously closed, Transaction.isActive() mis-reports that the transaction is still alive when it is not. I'll grant that the JavaDoc for isActive indicates it is the 'local transaction', not the underlying transaction, but since there is no way to delve into the underlying connection in the public API, that is really a cop-out. If you don't like the idea of modifying the behavior of isActive(), how about exposing a 'public Connection connection()' method that exposes the connection? -- 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

15 years, 10 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-1989) Deleted object remains referenced in 2nd level cache collections

by Justin Haddad (JIRA)

Deleted object remains referenced in 2nd level cache collections ---------------------------------------------------------------- Key: HHH-1989 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1989 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.cr2 Environment: Spring 1.2.8, Hibernate 3.2, Postgres 8.0.3 Reporter: Justin Haddad This problem seems identical to issue NH-678. I have enabled caching for an one-to-many association. I use Ehcache. I have a test in which I load the parent object along with its collection. Both the parent and the collection wind up in the 2nd level cache. I then delete an object that is in the collection, not by removing it from the collection, but rather by doing a delete on the object itself. After deleting, I try to reload the parent and get the following exception (User#3102 is the deleted object): aused by: org.hibernate.ObjectNotFoundException: No row with the given identifier exists: [com.bluenotenetworks.common.management.sm.User#3102] at org.hibernate.impl.SessionFactoryImpl$1.handleEntityNotFound(SessionFactoryImpl.java:372) at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:128) at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:178) at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:86) at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:871) at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:839) at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:266) at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177) at org.hibernate.collection.PersistentSet.initializeFromCache(PersistentSet.java:101) at org.hibernate.cache.entry.CollectionCacheEntry.assemble(CollectionCacheEntry.java:35) at org.hibernate.event.def.DefaultInitializeCollectionEventListener.initializeCollectionFromCache(DefaultInitializeCollectionEventListener.java:130) at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:48) at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1705) (continues on) I stepped through the code in the debugger and can see that the object's ID (3102 in this case) remains in the cached collection even after the deletion. -- 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

15 years, 10 months

3
2
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

15 years, 10 months

8
28
0 / 0

[Hibernate-JIRA] Created: (HHH-2041) Update with unaltered natural-id fails

by Jim Pease (JIRA)

Update with unaltered natural-id fails -------------------------------------- Key: HHH-2041 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2041 Project: Hibernate3 Type: Bug Components: core Versions: 3.1.3 Environment: hibernate-3.1.3, mysql-4.1.12 Reporter: Jim Pease This may be a duplicate of http://opensource.atlassian.com/projects/hibernate/browse/HHH-1574. Getting following error: caused by: org.hibernate.HibernateException: immutable natural identifier of an instance of edu.syr.lsb.gmt.impl.LinkImpl was altered at org.hibernate.event.def.DefaultFlushEntityEventListener.checkNaturalId(DefaultFlushEntityEventListener.java:80) at org.hibernate.event.def.DefaultFlushEntityEventListener.getValues(DefaultFlushEntityEventListener.java:155) at org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:106) at org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:195) at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:76) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:26) ... This is occurring without modifications to the natural identifier, which is mapped as follows: <natural-id> <property name="activityRef" column="ACTIVITY_REF" length="255" not-null="true" /> <many-to-one name="goal" class="GoalImpl" column="GOAL_ID" not-null="true" cascade="none" /> </natural-id> -- 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

15 years, 11 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-1992) Some cascade actions should not trigger a property access on lazy properties

by Emmanuel Bernard (JIRA)

Some cascade actions should not trigger a property access on lazy properties ---------------------------------------------------------------------------- Key: HHH-1992 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1992 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.cr3 Reporter: Emmanuel Bernard Assigned to: Emmanuel Bernard Priority: Critical Fix For: 3.2.0.ga -- 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

15 years, 11 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2584) PersistentMap.remove() incorrect on uninitialized, non-extra-lazy map

by Daniel Wellman (JIRA)

PersistentMap.remove() incorrect on uninitialized, non-extra-lazy map --------------------------------------------------------------------- Key: HHH-2584 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2584 Project: Hibernate3 Issue Type: Patch Components: core Affects Versions: 3.2.3, 3.2.2, 3.2.1 Environment: Hibernate 3.2.3 ga, MySQL 5.0.24a, for Win32 Reporter: Daniel Wellman Attachments: persistentmap_remove.patch This problem is nearly identical to HHH-2476: PersistentMap.put() incorrect on uninitialized, non-extra-lazy map. remove() has the same problem. See also issue HHH-2142. The write up for HHH-2476 was so concise that I will transform it here, substituting remove() for put(). --- Essentially, an uninitialized PersistentMap loses the first remove() into it if defined as non-extra-lazy. The underlying cause is the code in PersistentMap#remove() which attempts to readElementByIndex(). In the case of non-extra-lazy, readElementByIndex() returns the UNKNOWN marker object which is supposed to be used to signal that the delegate map is now initialized and to remove the element directly from the map. Long story short, PersistentMap#remove() does not properly check the return value from readElementByIndex() and react accordingly. -- 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

15 years, 11 months

8
12
0 / 0

[Hibernate-JIRA] Created: (HHH-2380) Hibernate3.2.0 GA is JDK 1.3 Incompatible

by Alessandro Lazarotti (JIRA)

Hibernate3.2.0 GA is JDK 1.3 Incompatible ----------------------------------------- Key: HHH-2380 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2380 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.ga Environment: Hibernate 3.2.0 GA Reporter: Alessandro Lazarotti Priority: Minor The class org.hibernate.persister.entity.AbstractEntityPersister uses Boolean.valueOf, incompatible with JDK 1.3. Update for new Boolean. -- 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

15 years, 11 months

4
8
0 / 0

[Hibernate-JIRA] Created: (HHH-2809) dialect changes: limit string

by Anthony Patricio (JIRA)

dialect changes: limit string ----------------------------- Key: HHH-2809 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2809 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.3 Reporter: Anthony Patricio Attachments: IngresDialect.svndiff32 In Ingres we use "SELECT FIRST $n col1,... FROM ..." to limit the resultset. The old dialect replaces the first 6 chars of the select statement with "SELECT FIRST $n". When running our partner application, hibernate has put 2 or 3 blanks at the begining of the query, which causes an error, of course. Patch attached -- 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

16 years

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2295) entity-name attribute's syntax not clearly documented

by Jeremy Michael Crosbie (JIRA)

entity-name attribute's syntax not clearly documented ----------------------------------------------------- Key: HHH-2295 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2295 Project: Hibernate3 Type: Bug Components: documentation Versions: 3.2.1 Environment: Windows XP/JDK 1.5/HypersonicSQL Reporter: Jeremy Michael Crosbie Priority: Minor Attachments: Group.hbm.xml Setting entity-name to a value containing a hyphen, in my case 'lender-group' causes odd behaviors seemingly only when calling get() or load(). Also in my case I am mapping a class to two different tables (attached). The first mapping has an entity name with a hyphen, the other does not. When I call load *after committing a transaction where a new entity is persisted* I get an exception (see below). The exception complains of a column called "LENDER" not existing. But once I change the entity-name to something like 'lendergroup' the problem goes away. Interestingly, the missing column complained about is the text before the hyphen, so if I name the entity 'lndr-group' it complains of a column name 'LNDR' not existing. It almost appears if this format is assuming some sort of discriminator, but the online docs are terse when it comes to describing the entity-name field. Exception: org.hibernate.exception.SQLGrammarException: could not load an entity: [lender-group#G9] at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:67) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) at org.hibernate.loader.Loader.loadEntity(Loader.java:1799) at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:47) at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:41) at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:2730) at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:365) at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:346) at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:123) at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:177) at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:87) at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:862) at org.hibernate.impl.SessionImpl.get(SessionImpl.java:799) 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.context.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:301) at $Proxy0.get(Unknown Source) at com.fares.mtrac.group.GroupDaoImpl.findById(GroupDaoImpl.java:148) at com.fares.mtrac.group.GroupDaoImplTest.testFindByIdStringCompanyType(GroupDaoImplTest.java:256) 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:164) at junit.framework.TestCase.runBare(TestCase.java:130) 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:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: java.sql.SQLException: Column not found: LENDER in statement [select lender-gro0_.group_cd as group1_48_0_, lender-gro0_.group_nm as group2_48_0_, lender-gro0_.user_nm as user3_48_0_ from lender_group_name lender-gro0_ where lender-gro0_.group_cd=?] at org.hsqldb.jdbc.Util.throwError(Unknown Source) at org.hsqldb.jdbc.jdbcPreparedStatement.<init>(Unknown Source) at org.hsqldb.jdbc.jdbcConnection.prepareStatement(Unknown Source) at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:442) at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:368) at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:105) at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1561) at org.hibernate.loader.Loader.doQuery(Loader.java:661) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224) at org.hibernate.loader.Loader.loadEntity(Loader.java:1785) ... 36 more -- 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

16 years

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2088) TypeMismatchException on object equality expression from one-to-one relationship

by Salvatore Insalaco (JIRA)

TypeMismatchException on object equality expression from one-to-one relationship -------------------------------------------------------------------------------- Key: HHH-2088 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2088 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.cr4 Reporter: Salvatore Insalaco Suppose to have entity A with a one-to-one constrained relationship to an entity B, called bRel. The query: "from A a, B b where a.bRel = b" raises a TypeMismatchException, even if bRel and b are instances of the same entity. This happens because in BinaryLogicOperatorNode: - lhsType is org.hibernate.type.Type = org.hibernate.type.OneToOneType(B)", with getColumnSpan returning 0. - rhsType is org.hibernate.type.Type = org.hibernate.type.ManyToOneType(B)", with getColumnSpan returning 1. And it compares the two columnspans. It doesn't happen with 3.2.0.cr2. -- 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

16 years

4
8
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues August 2007