March 2008 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Updated: (HHH-1582) PostInsertListener + "post-commit-insert"

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1582?page=c... ] Steve Ebersole updated HHH-1582: -------------------------------- Fix Version/s: (was: 3.3.0.CR1) 3.3.0 > PostInsertListener + "post-commit-insert" > ----------------------------------------- > > Key: HHH-1582 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1582 > Project: Hibernate3 > Issue Type: Bug > Affects Versions: 3.1.2 > Reporter: Daniel Gredler > Assignee: Emmanuel Bernard > Fix For: 3.3.0 > > Original Estimate: 3 hours > Remaining Estimate: 3 hours > > I'm using a custom PostInsertEventListener mapped to the "post-commit-insert" event to process domain objects. However, PostInsertEventListener's onPostInsert(PostInsertEvent) is getting called even when the insert was not successful (ie, due to a unique constraint in the database or some such). It looks to me like Hibernate should either a) not invoke the event listener if the insert failed or b) provide state (perhaps in the form of a boolean indicating success/failure). Personally I'd rather the method not be called on failure, but there may be use cases out there for the second option. > As an example, it looks like Hibernate's own LuceneEventListener will add a domain object to the index in onPostInsert(PostInsertEvent) even if the insert failed. > Note that this problem also seems to exist in EntityDeleteAction and EntityUpdateAction (which would mean that Hibernate's LuceneEventListener removes domain objects from the Lucene index even if the delete fails!). -- 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

18 years

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2863) testsuite fix-ups for maven and/or directory changes

by Steve Ebersole (JIRA)

testsuite fix-ups for maven and/or directory changes ---------------------------------------------------- Key: HHH-2863 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2863 Project: Hibernate3 Issue Type: Bug Components: testsuite Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.3 -- 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

18 years

1
3
0 / 0

[Hibernate-JIRA] Resolved: (HHH-1786) JTASessionContext.CleanupSynch does not remove sessions from currentSessionMap

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1786?page=c... ] Steve Ebersole resolved HHH-1786. --------------------------------- Resolution: Fixed > JTASessionContext.CleanupSynch does not remove sessions from currentSessionMap > ------------------------------------------------------------------------------ > > Key: HHH-1786 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1786 > Project: Hibernate3 > Issue Type: Improvement > Affects Versions: 3.1.2 > Environment: IBM WebSphere 6.0.2.7, Hibernate CVS snapshot from 2006-02-24 > Reporter: Tomi Szabo > Assignee: Steve Ebersole > Fix For: 3.3.0.CR1 > > Attachments: JTASessionContext.java, WebSphereExtendedJTATransactionLookup.java, WebSphereExtendedJTATransactionLookup.patch.txt > > > We are using JTASessionContext, CMTTransaction and WebSphereExtendedJTATransactionLookup. We have experienced some memmory leak problems and after closer inspection we have found that Hibernate sessions are not removed from currentSessionMap inside JTASessionContext. > Method JTASessionContext.CleanupSynch.afterCompletion() is called as expected but code "context.currentSessionMap.remove( txn );" does not remove session from Map because of key's hashcode has changed. This is due to fact that com.ibm.websphere.jtaextensions.ExtendedJTATransaction.hashCode is actually ID of underlaying transaction. But if it comes to the afterCompletion method in CleanupSynch the underlaying transaction is already closed. Closed transaction has ID 0 (default value) and it is different from ID under which the Hibernate session was previously inserted into Map. > Possible patch is in attachements. -- 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

18 years

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-521) Enabling hibernate.use_sql_comments fails

by Rafael Chaves (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-521?page=co... ] Rafael Chaves commented on HHH-521: ----------------------------------- A similar problem occurs with Postgres: http://archives.postgresql.org/pgsql-jdbc/2006-02/msg00168.php > Enabling hibernate.use_sql_comments fails > ----------------------------------------- > > Key: HHH-521 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-521 > Project: Hibernate3 > Issue Type: Bug > Environment: Hibernate 3.0.3 > Reporter: Mathias Bogaert > > When enabling hibernate.use_sql_comments I get the following exceptions: > INFO - SQLErrorCodes loaded: [DB2, HSQL, MS-SQL, MySQL, Oracle, Informix, PostgreSQL, Sybase] > Hibernate: /*criteria query*/select this_.USER_ID as USER1_0_, this_1_.LOGIN as LOGIN28_0_, this_1_.FIRST_NAME as FIRST3_28_0_, th > is_1_.LAST_NAME as LAST4_28_0_, this_1_.FULL_NAME as FULL5_28_0_, this_1_.EMAIL_ADDRESS as EMAIL6_28_0_, this_1_.STATUS as STATUS2 > 8_0_, this_1_.UNIT_ID as UNIT8_28_0_, this_.PHONE as PHONE30_0_, this_.COUNTRY_ISO as COUNTRY3_30_0_, this_.LAST_LOGIN as LAST4_30 > _0_, this_.LAST_PASSWORD_ENTERED as LAST5_30_0_, roles2_.USER_ID as USER1___, roles2_.ROLE_ID as ROLE2___ from AUD_USERS this_ inn > er join AUD_REF_USERS_VIEW this_1_ on this_.USER_ID=this_1_.USER_ID left outer join AUD_REF_USERS_ROLES_VIEW roles2_ on this_.USER > _ID=roles2_.USER_ID where this_1_.LOGIN=? > WARN - SQL Error: 1009, SQLState: 72000 > ERROR - ORA-01009: missing mandatory parameter > ERROR - Could not execute action > org.hibernate.exception.GenericJDBCException: could not execute query > at org.hibernate.exception.ErrorCodeConverter.handledNonSpecificException(ErrorCodeConverter.java:92) > at org.hibernate.exception.ErrorCodeConverter.convert(ErrorCodeConverter.java:80) > at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) > at org.hibernate.loader.Loader.doList(Loader.java:1565) > at org.hibernate.loader.Loader.list(Loader.java:1545) > at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:111) > at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1316) > at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:299) > at org.hibernate.impl.CriteriaImpl.uniqueResult(CriteriaImpl.java:432) > at eu.cec.regio.sysaudit.domain.reference.persistence.hibernate.HibernateReferenceDao.findUserByLogin(HibernateReferenceDa > o.java:311) > 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:324) > at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:287) > at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:155) > at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:122) > at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:57) > at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144) > at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:174) > at $Proxy65.findUserByLogin(Unknown Source) > at eu.cec.regio.sysaudit.security.OracleSecurityService.authenticate(OracleSecurityService.java:52) > at eu.cec.regio.sysaudit.web.action.security.MultipleRoleLogin.authenticate(MultipleRoleLogin.java:23) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > ... > with undelying trace: > Caused by: java.sql.SQLException: ORA-01009: missing mandatory parameter > at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134) > at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:289) > at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:582) > at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1983) > at oracle.jdbc.ttc7.TTC7Protocol.fetch(TTC7Protocol.java:1250) > at oracle.jdbc.driver.OracleResultSetImpl.next(OracleResultSetImpl.java:295) > at weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_OracleResultSetImpl.next(Unknown Source) > at org.hibernate.loader.Loader.doQuery(Loader.java:391) > at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:210) > at org.hibernate.loader.Loader.doList(Loader.java:1562) -- 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

18 years

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1268) Unidirection OneToMany causes duplicate key entry violation when removing from list

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1268?page=c... ] Steve Ebersole updated HHH-1268: -------------------------------- Fix Version/s: (was: 3.3.0.CR1) 3.3.0 > Unidirection OneToMany causes duplicate key entry violation when removing from list > ----------------------------------------------------------------------------------- > > Key: HHH-1268 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1268 > Project: Hibernate3 > Issue Type: Bug > Affects Versions: 3.1 > Environment: 3.1 final > MySql 4.1.14 using MYISAM tables > Reporter: Rex Madden > Assignee: Gail Badner > Fix For: 3.2.x, 3.3.0 > > Attachments: src.zip > > > Simple OneToMany parent/child relationship using the default table structure (2 tables and a join table) > Add 3 children to the parent. Flush. Remove the first child. Flush throws error: > Exception in thread "main" org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update > at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:69) > at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) > at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:202) > at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:230) > at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:143) > at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:296) > at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) > at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:980) > at UnidirectionalOneToManyRemoveFromListBug.main(UnidirectionalOneToManyRemoveFromListBug.java:27) > 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:86) > Caused by: java.sql.BatchUpdateException: Duplicate key or integrity constraint violation, message from server: "Duplicate entry '5' for key 2" > at com.mysql.jdbc.PreparedStatement.executeBatch(PreparedStatement.java:1461) > at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:58) > at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:195) > ... 11 more > The problem is that there is a unique key on the relationship table that gets violated. The session removes the last row in the relationship table, then attempts to rewrite the child_id's. It fails since there is a uniqueness constraint on that column. -- 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

18 years

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2702) Officially move to JDK 1.4

by Steve Ebersole (JIRA)

Officially move to JDK 1.4 -------------------------- Key: HHH-2702 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2702 Project: Hibernate3 Issue Type: Task Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.3 This includes a number of considerations, such as (1) assuming JDBC3 as a baseline, (2) using the improved collections, etc. This will act as the grouping task for all JDK 1.4 migration tasks. -- 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

18 years

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2704) Migrate to Maven2 for build

by Steve Ebersole (JIRA)

Migrate to Maven2 for build --------------------------- Key: HHH-2704 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2704 Project: Hibernate3 Issue Type: Task Components: build Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.3 This is the *official* move to Maven2 issue (since I'm the only one willing to actually do 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

18 years

4
7
0 / 0

[Hibernate-JIRA] Created: (HHH-2555) Create new RegionFactory for JBossCache

by Steve Ebersole (JIRA)

Create new RegionFactory for JBossCache --------------------------------------- Key: HHH-2555 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2555 Project: Hibernate3 Issue Type: New Feature Components: caching (L2) Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.3 Based on discussions ongoing between the Hibernate and JBossCache teams, create a new RegionFactory which takes fulfills the discussed requirements. These requirements are spread throughout: (1) JBC wiki : http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheHibernateAlignment (2) email thread : http://www.mail-archive.com/hibernate-dev%40lists.jboss.org/msg01055.html (plus a few others referenced within the above resources). -- 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

18 years

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3140) Region prefix ignored for entities and collections

by Brian Stansberry (JIRA)

Region prefix ignored for entities and collections -------------------------------------------------- Key: HHH-3140 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3140 Project: Hibernate3 Issue Type: Bug Components: caching (L2) Affects Versions: 3.3 Reporter: Brian Stansberry Fix For: 3.3 The way hibernate handles hibernate.cache.region_prefix varies between the Region types. When RegionFactory.buildQueryResultsRegion() and buildTimestampsRegion() are called, any region_prefix is prepended to the passed regionName. With entities and collection's it is not. (01:45:56 PM) besYIM: well, I looked in hibernate-core for usages of Settings.getCacheRegionPrefix() and the only usage was in the StandardQueryCache and UpdateTimestampsCache classes (01:48:48 PM) steve_ebersole78613: oh, i think i just missed that for entity and collections (01:49:02 PM) steve_ebersole78613: it used to be handled by a class no longer there -- 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

18 years

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3188) Criteria: expose whether restrictions have been added

by Paul Benedict (JIRA)

Criteria: expose whether restrictions have been added ----------------------------------------------------- Key: HHH-3188 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3188 Project: Hibernate3 Issue Type: Improvement Components: query-criteria Affects Versions: 3.3 Reporter: Paul Benedict Creating a criteria with no restrictions queries all instances. That's expected and fine. However, I see a lot of business services which will translate a search DTO into a Criteria instance, and there's no clean way of determining when the criteria actually has restrictions attached. Example: Criteria crit = ...createCriteria(...); if (dto.getComponent2() != null) { // translate properties } if (dto.getComponent2() != null) { // translate properties } if (crit.isRestricted() { // Proposal // do real search } else { return; } -- 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

18 years

1
0
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 March 2008