January 2008 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Commented: (HHH-1956) Interceptor.afterTransactionCompletion not called with JTATransaction (CacheSynchronization.hibernateTransaction not set)

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1956?page=c... ] Steve Ebersole commented on HHH-1956: ------------------------------------- qualification of "whenever we register a synch should be a viable trigger event"... specifically talking about the code (currently) in org.hibernate.jdbc.JDBCContext#registerSynchronizationIfPossible (~ line 169) where we register the JTA synch: tx.registerSynchronization( new CacheSynchronization(owner, this, tx, null) ); isTransactionCallbackRegistered = true; log.debug("successfully registered Synchronization"); return true; (note that the null param to the CacheSynchronization ctor here is supposed to be the hibernateTransaction...) becoming something like: Transaction hibernateTransaction = this.hibernateTransaction; if ( hibernateTransaction == null ) { hibernateTransaction = owner.getFactory().getSettings().getTransactionFactory().createTransaction( this, owner ); } tx.registerSynchronization( new CacheSynchronization(owner, this, tx, hibernateTransaction) ); isTransactionCallbackRegistered = true; if ( this.hibernateTransaction == null ) { this.hibernateTransaction = hibernateTransaction; } log.debug("successfully registered Synchronization"); return true; The difference being that the hibernateTransaction is no longer null in these JTA scenarios we are discussing... > Interceptor.afterTransactionCompletion not called with JTATransaction (CacheSynchronization.hibernateTransaction not set) > ------------------------------------------------------------------------------------------------------------------------- > > Key: HHH-1956 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1956 > Project: Hibernate3 > Issue Type: Bug > Components: core > Affects Versions: 3.1.2 > Environment: JBoss 4.0.3SP1 under Windows XP > Reporter: Eric Sword > Assignee: Steve Ebersole > Fix For: 3.2.6, 3.3 > > > interceptor.afterTransactionCompletion should be invoked in SessionImpl.afterTransactionCompletion, but it is only called if the tx parameter is not null. When running under a JTA environment, that parameter will always be null. This is the stack which leads to the call (line numbers are from v3.1.2 code): > org.hibernate.impl.SessionImpl.afterTransactionCompletion(boolean, org.hibernate.Transaction) line: 442 > org.hibernate.jdbc.JDBCContext.afterTransactionCompletion(boolean, org.hibernate.Transaction) line: 205 > org.hibernate.transaction.CacheSynchronization.afterCompletion(int) line: 85 > org.jboss.tm.TransactionImpl.doAfterCompletion() line: 1508 > org.jboss.tm.TransactionImpl.completeTransaction() line: 1180 > org.jboss.tm.TransactionImpl.commit() line: 359 > org.jboss.tm.TxManager.commit() line: 224 > org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit() line: 126 > org.hibernate.transaction.JTATransaction.commit() line: 146 > The problem is that the hibernateTransaction member variable of the CacheSynchronization object is never set. Here is the call stack for how that object is created: > org.hibernate.transaction.CacheSynchronization.<init>(org.hibernate.transaction.TransactionFactory$Context, org.hibernate.jdbc.JDBCContext, javax.transaction.Transaction, org.hibernate.Transaction) line: 34 > org.hibernate.jdbc.JDBCContext.registerSynchronizationIfPossible() line: 149 > org.hibernate.transaction.JTATransaction.begin() line: 102 > org.hibernate.impl.SessionImpl.beginTransaction() line: 1309 > com.osc.util.hibernate.HibernateManager.getSession(org.hibernate.Interceptor) line: 204 > You can see in the JDBCContext.registerSynchronizationIfPossible() method that the parameter to set the transaction is always null, even though the JDBCContext object does have a reference to the hibernateTransaction at that point. The CacheSynchronization only uses that reference for beforeTransactionCompletion and afterTransactionCompletion calls. The beforeTransactionCompletion works because the SessionImpl.beforeTransactionCompletion call doesn't check if the tx is null, while the afterTransactionCompletion does. -- 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

17 years, 10 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1956) Interceptor.afterTransactionCompletion not called with JTATransaction (CacheSynchronization.hibernateTransaction not set)

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1956?page=c... ] Steve Ebersole updated HHH-1956: -------------------------------- Assignee: Steve Ebersole Fix Version/s: 3.3 3.2.6 There seem to be 2 approaches to solving this: 1) skip the checks about null hibernateTransaction 2) make sure a hibernateTransaction is present in these scenarios (whenever we register a synch should be a viable trigger event). > Interceptor.afterTransactionCompletion not called with JTATransaction (CacheSynchronization.hibernateTransaction not set) > ------------------------------------------------------------------------------------------------------------------------- > > Key: HHH-1956 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1956 > Project: Hibernate3 > Issue Type: Bug > Components: core > Affects Versions: 3.1.2 > Environment: JBoss 4.0.3SP1 under Windows XP > Reporter: Eric Sword > Assignee: Steve Ebersole > Fix For: 3.2.6, 3.3 > > > interceptor.afterTransactionCompletion should be invoked in SessionImpl.afterTransactionCompletion, but it is only called if the tx parameter is not null. When running under a JTA environment, that parameter will always be null. This is the stack which leads to the call (line numbers are from v3.1.2 code): > org.hibernate.impl.SessionImpl.afterTransactionCompletion(boolean, org.hibernate.Transaction) line: 442 > org.hibernate.jdbc.JDBCContext.afterTransactionCompletion(boolean, org.hibernate.Transaction) line: 205 > org.hibernate.transaction.CacheSynchronization.afterCompletion(int) line: 85 > org.jboss.tm.TransactionImpl.doAfterCompletion() line: 1508 > org.jboss.tm.TransactionImpl.completeTransaction() line: 1180 > org.jboss.tm.TransactionImpl.commit() line: 359 > org.jboss.tm.TxManager.commit() line: 224 > org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit() line: 126 > org.hibernate.transaction.JTATransaction.commit() line: 146 > The problem is that the hibernateTransaction member variable of the CacheSynchronization object is never set. Here is the call stack for how that object is created: > org.hibernate.transaction.CacheSynchronization.<init>(org.hibernate.transaction.TransactionFactory$Context, org.hibernate.jdbc.JDBCContext, javax.transaction.Transaction, org.hibernate.Transaction) line: 34 > org.hibernate.jdbc.JDBCContext.registerSynchronizationIfPossible() line: 149 > org.hibernate.transaction.JTATransaction.begin() line: 102 > org.hibernate.impl.SessionImpl.beginTransaction() line: 1309 > com.osc.util.hibernate.HibernateManager.getSession(org.hibernate.Interceptor) line: 204 > You can see in the JDBCContext.registerSynchronizationIfPossible() method that the parameter to set the transaction is always null, even though the JDBCContext object does have a reference to the hibernateTransaction at that point. The CacheSynchronization only uses that reference for beforeTransactionCompletion and afterTransactionCompletion calls. The beforeTransactionCompletion works because the SessionImpl.beforeTransactionCompletion call doesn't check if the tx is null, while the afterTransactionCompletion does. -- 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

17 years, 10 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-3074) Remove lib/jdbc2_0-stdext.jar since it is no longer needed

by Gail Badner (JIRA)

Remove lib/jdbc2_0-stdext.jar since it is no longer needed ---------------------------------------------------------- Key: HHH-3074 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3074 Project: Hibernate3 Issue Type: Improvement Components: core Reporter: Gail Badner Assignee: Gail Badner Fix For: 3.2.6 lib/jdbc2_0-stdext.jar is only needed for JDK versions prior to 1.4. Since the hibernate core build targets Java 1.4, this jar can be removed. -- 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

17 years, 10 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3089) Detailed explanation on how to call Oracle stored procedure from hibernate mapping file.

by Yamini Seshadri (JIRA)

Detailed explanation on how to call Oracle stored procedure from hibernate mapping file. ----------------------------------------------------------------------------------------- Key: HHH-3089 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3089 Project: Hibernate3 Issue Type: Task Reporter: Yamini Seshadri Please help me with a detailed code snippet of how to call Oracle stored procedure from hibernate mapping file. The procedure returns one OUT Parameter. Also pls help me in processing the OUT parameter in java file once called from hibernate mapping file. Need to immediate help. Post ur replies to: yamini.v.s(a)cognizant.com Thanks in advance Yamini -- 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

17 years, 11 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3088) Collection "remove" events don't contain removed collection when detached entity is updated with a null collection

by Gail Badner (JIRA)

Collection "remove" events don't contain removed collection when detached entity is updated with a null collection ------------------------------------------------------------------------------------------------------------------ Key: HHH-3088 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3088 Project: Hibernate3 Issue Type: Bug Components: core Reporter: Gail Badner Assignee: Gail Badner When a detached entity is updated with a null collection using Session.update(), the collection is deleted without being loaded. For this reason, pre- and post- collection-remove events contain a null collection, instead of the collection that was removed. A "FailureExpected" test case was added to org.hibernate.test.event.collection.BrokenCollectionEventTest, testUpdateDetachedParentNoChildrenToNullFailureExpected, which fails because the collection in the pre- and post-collection-remove events are expected to contain the collection being removed. Another test case, testUpdateDetachedParentOneChildToNullFailureExpected, is commented out since it fails for the same reason. When this is fixed, both test case should be moved to org.hibernate.test.event.collection.AbstractCollectionEventTest. -- 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

17 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-3087) No collection create eventst when collection is set to null

by Gail Badner (JIRA)

No collection create eventst when collection is set to null ----------------------------------------------------------- Key: HHH-3087 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3087 Project: Hibernate3 Issue Type: Bug Components: core Reporter: Gail Badner Assignee: Gail Badner When an entity is saved or updated with a null collection, pre- and post-collection-recreate events are not generated. These events are generated when saving or updating an entity with an empty collection. Two "FailureExpected" tests have been added to org.hibernate.test.event.collection.BrokenCollectionEventTest:, which fail because the test case expects pre- and post-collection-recreate events to be generated: - testSaveParentNullChildrenFailureExpected: a parent entity with an empty collection is saved with a null collection - testUpdateParentNoChildrenToNullFailureExpected: a parent entity that has been persisted with a non-null collection is updated with a null collection. The following two tests have been also been added, but are commented out because they fail for the same reason as testUpdateParentNoChildrenToNullFailureExpected: - testUpdateParentOneChildToNullFailureExpected: a parent entity that has been persisted with an non-empty collection is saved with a null collection - testUpdateMergedParentOneChildToNullFailureExpected: a detached parent entity that has been persisted with a non-empty collection is merged into a session with a null collection When this bug is fixed, all 4 tests should be moved to org.hibernate.test.event.collection.AbstractCollectionEventTest. -- 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

17 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2616) No event is fired on Collection recreate/remove/update action

by Emmanuel Bernard (JIRA)

No event is fired on Collection recreate/remove/update action ------------------------------------------------------------- Key: HHH-2616 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2616 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.4 Reporter: Emmanuel Bernard There is no way today to know if a collection has been updated (in the generic sense of it) managedEntity.getCollection().add(object) fires no event. Seems to me that it should fire Pre/PostUpdateEvent. Because of PostUpdateEvent signature we might need a PostUpdateCollectionEvent (Update meaning Update/Create/Delete) -- 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

17 years, 11 months

5
7
0 / 0

[Hibernate-JIRA] Created: (HHH-3086) Remove jdbc2_0-stdext.jar (unnecessary library)

by Steve Ebersole (JIRA)

Remove jdbc2_0-stdext.jar (unnecessary library) ----------------------------------------------- Key: HHH-3086 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3086 Project: Hibernate3 Issue Type: Task Components: core Affects Versions: 3.2.5 Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.2.6 move to jdk 1.4 made this unnecessary, but it was never removed... -- 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

17 years, 11 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3085) Remove connector.jar (unnecessary library)

by Steve Ebersole (JIRA)

Remove connector.jar (unnecessary library) ------------------------------------------ Key: HHH-3085 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3085 Project: Hibernate3 Issue Type: Task Components: core Affects Versions: 3.2.5 Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.2.6 Clean up connector.jar; left over from (now removed) JCA features. -- 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

17 years, 11 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HSHARDS-50) Bug in annotation example coe

by Max Ross (JIRA)

Bug in annotation example coe ----------------------------- Key: HSHARDS-50 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSHARDS-50 Project: Hibernate Shards Issue Type: Bug Components: documentation Affects Versions: 3.0.0.Beta2 Reporter: Max Ross Assignee: Max Ross Priority: Trivial Fix For: 3.0.0 In the Annotation example in the documentation, the type of the field annotated with @Id is Integer but we're using ShardedUUIDGenerator, which returns BigInteger. -- 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

17 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues January 2008