April 2008 - hibernate-issues - Jboss List Archives

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

by Michael Newcomb (JIRA)

PersistentMap.remove() incorrect on uninitialized, non-extra-lazy map --------------------------------------------------------------------- Key: HHH-3223 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3223 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.3.0.CR1 Reporter: Michael Newcomb Please have a look at PersistentMap.remove() and compare it to PersistentMap.put(). The put() was fixed HHH-2476 and the same fix needs to be applied to remove(). Please refer to HHH-2584 for the patch: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2584 Copied from HHH-2584: 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. WORKAROUND: Have a copy of PersistentMap.java in your source tree with the patch applied... Thanks! -- 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

4
8
0 / 0

[Hibernate-JIRA] Created: (HHH-3028) Memory consumption when query cache is enabled

by Markus Heiden (JIRA)

Memory consumption when query cache is enabled ---------------------------------------------- Key: HHH-3028 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028 Project: Hibernate3 Issue Type: Bug Components: caching (L2), core Affects Versions: 3.2.5 Environment: Hibernate 3.2.5, Oracle 9i Reporter: Markus Heiden As discussed in the hibernate-dev mailing list from 9.11.2007 to 12.11.2007 this bug describes a memory consumption issue which is located in ActionQueue/EntityAction. Some snippets from ActionQueue: private ArrayList executions; public void execute(Executable executable) { final boolean lockQueryCache = session.getFactory().getSettings().isQueryCacheEnabled(); if ( executable.hasAfterTransactionCompletion() || lockQueryCache ) { executions.add( executable ); } ... } This code leads to a kind of memory leak, because if the "executable" is added to "executions", the related entity which is referenced from the "executable" is prevented from being garbage collected until the transaction ends. So if one needs to insert large amounts of transient objects in one transaction, there is no chance to get rid of the inserted objects by flushing and evicting them, if e.g. the query cache is enabled. One solution to this problem might be to rework the above "if" condition to only add objects to "executions" if this is really needed. The problem is to determine when it is really needed. Some snippets from EntityAction (which implements Executable): private final Object instance; public final Serializable getId() { if ( id instanceof DelayedPostInsertIdentifier ) { return session.getPersistenceContext().getEntry( instance ).getId(); } return id; } public final Object getInstance() { return instance; } Another solution might be to set the reference to the related entity (field "instance" in EntityAction) to null after flushing. This does not prevent "executions" from being filled, but the related entities might be garbage collected and so the memory consumption is acceptable. The problem is that subclasses of EntityAction use the "instance" field for post transaction work. The are currently two workarounds to this problems: 1) To always disable the query cache 2) To use shorter transactions Workaround 1 is not really acceptable, because it prohibits the use of a very useful feature. Workaround 2 is sometimes acceptable but not wanted in most cases, because it breaks transactional safety. -- 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

8
12
0 / 0

[Hibernate-JIRA] Created: (HHH-2449) Lazy loading for one-to-one asociations

by jose (JIRA)

Lazy loading for one-to-one asociations --------------------------------------- Key: HHH-2449 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2449 Project: Hibernate3 Type: New Feature Components: core Versions: 3.2.2 Environment: Hibernate 3.2.2 Reporter: jose After read "Some explanations on lazy loading" and my tests I found a lossing feature in Hibernate (3.2.2). one-to-one with lazy="proxy"_____________________________________________ Hibernate ALWAYS launch selects to know if one-to-one is null or can be proxied. one-to-one with lazy="no-proxy"__________________________________________ Instrumentation allows to hibernate modify the getter to allows lazy loading on demand: * but allways initialize ALL no-proxy relations (with first getter call) -> must initialize ONLY the requested property * never auto-initialize FETCH joins, ALWAYS doit on demand (if opened session) -> must auto-initialize ONLY the FETCHED property note: Can submit a fix for this? How? NEW FEATURE: one-to-one with lazy="proxy" without multiple SELECTS______ If Hibernate adds join, for all one-to-one relations, to get the foreign-key of other tables, can check it to create a proxy or null. note: that hibernate adds joins for hierarchy, why not for one-to-one relations? This solution avoids: * 'multiple subselects' after first select * 'instrumentation' of bytecode -- 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, 10 months

3
2
0 / 0

[Hibernate-JIRA] Created: (ANN-614) @WhereJoinTable doesn't work with @ManyToOne

by Victor (JIRA)

@WhereJoinTable doesn't work with @ManyToOne -------------------------------------------- Key: ANN-614 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-614 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.3.0.ga Reporter: Victor @ManyToOne( fetch=FetchType.LAZY ) @JoinTable(name="CATEGORY_PRODUCT", uniqueConstraints = @UniqueConstraint(columnNames = {"PDID", "CATID"}), joinColumns = @JoinColumn(name="PDID"), inverseJoinColumns = @JoinColumn(name="CATID") ) @WhereJoinTable(clause="CATMAIN=1") protected Category getMainCategory() { return mainCategory; } protected void setMainCategories(Category mainCategory) { this.mainCategory = mainCategory; } Best regards, Victor -- 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, 10 months

5
5
0 / 0

[Hibernate-JIRA] Created: (HHH-3029) use_sql_commants fails on Derby

by Oleksandr Alesinskyy (JIRA)

use_sql_commants fails on Derby ------------------------------- Key: HHH-3029 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3029 Project: Hibernate3 Issue Type: Bug Environment: WinXP, SP2 Java 1.5..0_12, Spring 2.0.7, Hibernate 3.2.5ga, Derby 10.3.2.1 Reporter: Oleksandr Alesinskyy Activation is use_sql_comments cause SQL exception /* insert de.ntec.lms.impl.P1Bean */ insert into P1 (VERSION, CELL_POS, CODE, CELL_ID, PLACE_ID) values (?, ?, ?, ?, ?) 2007-12-25 11:46:29,406 WARN org.hibernate.util.JDBCExceptionReporter SQL Error: -1, SQLState: 42X01 2007-12-25 11:46:29,406 ERROR org.hibernate.util.JDBCExceptionReporter Syntaxfehler: Encountered "/" at line 1, column 1. 2007-12-25 11:46:29,487 ERROR org.hibernate.event.def.AbstractFlushingEventListener Could not synchronize database state with session org.hibernate.exception.SQLGrammarException: could not insert: [de.ntec.lms.impl.P1Bean] at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:67) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2078) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2427) at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:51) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:248) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:232) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:139) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:297) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:985) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:333) at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106) at de.ntec.lms.impl.PerformanceTest.doMain(PerformanceTest.java:84) at de.ntec.lms.impl.PerformanceTest.main(PerformanceTest.java:46) Caused by: java.sql.SQLException: Syntaxfehler: Encountered "/" at line 1, column 1. at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source) at org.apache.derby.client.am.Connection.prepareStatement(Unknown Source) at org.apache.commons.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:185) at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.prepareStatement(PoolingDataSource.java:278) at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:442) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:93) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:86) at org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:171) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2048) ... 12 more Caused by: org.apache.derby.client.am.SqlException: Syntaxfehler: Encountered "/" at line 1, column 1. at org.apache.derby.client.am.Statement.completeSqlca(Unknown Source) at org.apache.derby.client.net.NetStatementReply.parsePrepareError(Unknown Source) at org.apache.derby.client.net.NetStatementReply.parsePRPSQLSTTreply(Unknown Source) at org.apache.derby.client.net.NetStatementReply.readPrepareDescribeOutput(Unknown Source) at org.apache.derby.client.net.StatementReply.readPrepareDescribeOutput(Unknown Source) at org.apache.derby.client.net.NetStatement.readPrepareDescribeOutput_(Unknown Source) at org.apache.derby.client.am.Statement.readPrepareDescribeOutput(Unknown Source) at org.apache.derby.client.am.PreparedStatement.readPrepareDescribeInputOutput(Unknown Source) at org.apache.derby.client.am.PreparedStatement.flowPrepareDescribeInputOutput(Unknown Source) at org.apache.derby.client.am.PreparedStatement.prepare(Unknown Source) at org.apache.derby.client.am.Connection.prepareStatementX(Unknown Source) ... 20 more Hibernate settings (via Spring) <property name="manglableMappingResources"> <list> <value>de/ntec/lms/impl/P1Bean.hbm.xml</value> </list> </property> <property name="hibernateProperties"> <props> <prop key="hibernate.dialect">org.hibernate.dialect.DerbyDialect</prop> <prop key="hibernate.show_sql">true</prop> <prop key="hibernate.format_sql">true</prop> <prop key="hibernate.use_sql_comments">true</prop> <prop key="hibernate.cglib.use_reflection_optimizer">false</prop> </props> </property> When use_sql_comments is false all works smoothly. Failing code P1Bean p1= new P1Bean(); p1.setCell(1); p1.setCellPosition(2); p1.setCode("A"); s.save(p1); -- 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, 10 months

3
13
0 / 0

[Hibernate-JIRA] Created: (HHH-2646) Informix 10 dialect with BLOB/CLOB support

by Thomas Much (JIRA)

Informix 10 dialect with BLOB/CLOB support ------------------------------------------ Key: HHH-2646 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2646 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.2.4.sp1 Environment: Informix 10 Reporter: Thomas Much Priority: Minor We discovered that Informix 10 works well with mapping types "blob" and "clob" if we use our own dialect that's simply derived from the existing Informix dialect by adding the two missing types: public class Informix10Dialect extends InformixDialect { public Informix10Dialect() { super(); registerColumnType( Types.BLOB, "blob" ); registerColumnType( Types.CLOB, "clob" ); } } We suggest adding this new dialect to Hibernate Core. (This is similar to issue HHH-2523, but here "clob" is mapped, too.) -- 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, 10 months

4
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2059) Section 19.2 of the documentation does not show Ehcache as supporting clusters. It does.

by Greg Luck (JIRA)

Section 19.2 of the documentation does not show Ehcache as supporting clusters. It does. ----------------------------------------------------------------------------------------- Key: HHH-2059 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2059 Project: Hibernate3 Type: Bug Components: documentation Versions: 3.2.0 cr1, 3.2.0.cr2, 3.2.0.cr3, 3.2.0.cr4 Reporter: Greg Luck Priority: Minor Section 19.2 of the documentation does not show Ehcache as supporting clusters. It does. The only reason I am asking for this is that people are confused about it and are asking me questions over at the ehcache project. e.g. see the following email to the list. From: p.perrucci(a)gmail.com Subject: [ehcache-list] Using ehcache as a clustered cache in hibernate3 Date: 6 September 2006 6:29:21 PM GMT+10:00 To: ehcache-list(a)lists.sourceforge.net Hi all, current version of ehcache implements distributed caching but hibernate3 docs says that ehcache is not cluster safe. Anyone know the reason why it's not possible to use ehcache in such a scenario? Thanks Paolo ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642_... ehcache-list mailing list ehcache-list(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ehcache-list -- 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, 10 months

6
5
0 / 0

[Hibernate-JIRA] Created: (HHH-3112) Upgrade EhCache dependancy to 1.2.4+

by Stevo Slavic (JIRA)

Upgrade EhCache dependancy to 1.2.4+ ------------------------------------ Key: HHH-3112 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3112 Project: Hibernate3 Issue Type: Improvement Components: caching (L2) Affects Versions: 3.2.5 Reporter: Stevo Slavic Priority: Trivial Hibernate is widely used in conjunction with Spring framework. Spring framework as of version 2.0 expects EhCache to be 1.2.4+. When using both EhCache 1.2.4+ and Hibernate 3.2.5.ga as dependency in same maven project but in different sub-projects, older EhCache 1.2.3 (current Hibernate 3.2.5.ga dependency) can overwrite dependency application has for newer EhCache ( http://forum.springframework.org/showthread.php?t=49956 ). If Hibernate would use 1.2.4+ EhCache there would be no need to specify separate EhCache dependency. -- 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, 10 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-35) Look for log and exception strategy

by Emmanuel Bernard (JIRA)

Look for log and exception strategy ----------------------------------- Key: HSEARCH-35 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-35 Project: Hibernate Search Type: Task Components: mapping, query, engine, directory provider Reporter: Emmanuel Bernard Priority: Minor Fix For: 3.0.0.beta2 -- 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, 10 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3031) Include "FOR READ ONLY" hint in non-locking DB2 statements

by Steve Finch (JIRA)

Include "FOR READ ONLY" hint in non-locking DB2 statements ---------------------------------------------------------- Key: HHH-3031 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3031 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.2.5 Environment: 3.2.5, DB2/UDB 8.1+ Reporter: Steve Finch As per the DB2 documentation: http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.i... The FOR READ ONLY clause indicates that the result table is read-only and therefore the cursor cannot be referred to in Positioned UPDATE and DELETE statements. FOR FETCH ONLY has the same meaning. For result tables in which updates and deletes are allowed, specifying FOR READ ONLY (or FOR FETCH ONLY) can possibly improve the performance of FETCH operations by allowing the database manager to do blocking. For example, in programs that contain dynamic SQL statements without the FOR READ ONLY or ORDER BY clause, the database manager might open cursors as if the FOR UPDATE clause were specified. It is recommended, therefore, that the FOR READ ONLY clause be used to improve performance, except in cases where queries will be used in positioned UPDATE or DELETE statements. A read-only result table must not be referred to in a Positioned UPDATE or DELETE statement, whether it is read-only by nature or specified as FOR READ ONLY (FOR FETCH ONLY). The aforementioned improvement can be achieved by applying "FOR READ ONLY" when other locking hints are not specified. Patch to be uploaded soon. -- 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, 10 months

5
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues April 2008