[Hibernate-JIRA] Reopened: (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 reopened HHH-1786:
---------------------------------
Missed a commit
> 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.CR2
>
> Attachments: JTASessionContext.java, screenshot-1.jpg, screenshot-2.jpg, 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
17 years, 10 months
[Hibernate-JIRA] Updated: (HHH-1786) JTASessionContext.CleanupSynch does not remove sessions from currentSessionMap
by Lakshmi (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1786?page=c... ]
Lakshmi updated HHH-1786:
-------------------------
Attachment: screenshot-2.jpg
Tested with the JTASessionContext patch on 3.2.5ga and it works as expected. Thanks for the patch. Sessions are cleared from currentSessionMap on transaction completion. This is high priority bug for us as we are unable to run the application (hibernate 3.2.5 + WAS 6.0.2.21 + CMT) for 5 hour performance run continuously without the patch. Migrating to 3.3.0CR1 did not fix the issue.
> 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, screenshot-1.jpg, screenshot-2.jpg, 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
17 years, 10 months
[Hibernate-JIRA] Updated: (HHH-1786) JTASessionContext.CleanupSynch does not remove sessions from currentSessionMap
by Lakshmi (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1786?page=c... ]
Lakshmi updated HHH-1786:
-------------------------
Attachment: screenshot-1.jpg
Tested with 3.3.0CR1 on WASND 6.0.2.17 and find that the sessions are not being removed from currentSesssionMap.
> 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, screenshot-1.jpg, 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
17 years, 10 months
[Hibernate-JIRA] Commented: (HHH-672) bug in ComponentType isModified method ClassCastException (dom4j)
by Stephane Epardaud (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-672?page=co... ]
Stephane Epardaud commented on HHH-672:
---------------------------------------
I still have this bug, how can it not be fixed in 2008 with the proposed patch?
> bug in ComponentType isModified method ClassCastException (dom4j)
> -----------------------------------------------------------------
>
> Key: HHH-672
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-672
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Affects Versions: 3.1 rc3
> Environment: Hibernate 3.1 (stream), oracle 9.02
> Reporter: Jessica Marchiori
>
> There is a bug with the EntityMode.DOM4j in class ComponentType method isModified. The association of oldValues causes a ClassCastException
> The original code was
> public boolean isModified(Object old, Object current, SessionImplementor session)
> throws HibernateException {
> if ( current == null ) return old != null;
> if ( old == null ) return current != null;
> Object[] currentValues = getPropertyValues( current, session );
> Object[] oldValues = ( Object[] ) old;
> }
>
> for ( int i = 0; i < currentValues.length; i++ ) {
> if ( propertyTypes[i].isModified( oldValues[i], currentValues[i], session ) ) {
> return true;
> }
> }
> return false;
> }
> I have changed the code as below
> public boolean isModified(Object old, Object current, SessionImplementor session)
> throws HibernateException {
> if ( current == null ) return old != null;
> if ( old == null ) return current != null;
> Object[] currentValues = getPropertyValues( current, session );
> Object[] oldValues = getPropertyValues( old, session );
>
> for ( int i = 0; i < currentValues.length; i++ ) {
> if ( propertyTypes[i].isModified( oldValues[i], currentValues[i], session ) ) {
> return true;
> }
> }
> return false;
> }
> and it works
--
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
[Hibernate-JIRA] Created: (HHH-3301) Inconsistencies in association examples
by Peter Merker (JIRA)
Inconsistencies in association examples
---------------------------------------
Key: HHH-3301
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3301
Project: Hibernate3
Issue Type: Improvement
Components: documentation
Environment: Doesn't matter
Reporter: Peter Merker
Priority: Minor
The examples for association mappings are inconsistent. For example, regarding bidirectional associations, it suffices to set the "unique" attribute in one of the two mapping files, as it is done in the code example for §7.5.1. The mapping file for "Address" doesn't contain any "unique" attribute (and thus can either represent a "one" or a "many" side). But in the example for §7.5.2. we see:
<class name="Person">
<id name="id" column="personId">
<generator class="native"/>
</id>
<join table="PersonAddress"
optional="true">
<key column="personId"
unique="true"/> <!-- 1 -->
<many-to-one name="address"
column="addressId"
not-null="true"
unique="true"/> <!-- 2 -->
</join>
</class>
<class name="Address">
<id name="id" column="addressId">
<generator class="native"/>
</id>
<join table="PersonAddress"
optional="true"
inverse="true">
<key column="addressId"
unique="true"/> <!-- 3 -->
<many-to-one name="person"
column="personId"
not-null="true"
unique="true"/> <!-- 4 -->
</join>
</class>
The occurrences marked with "3" and "4" are superfluous, I checked with hbm2ddl (adding class attributes to the many-to-ones). Even if you delete them, you always get
"create table PersonAddress (personId integer not null unique, addressId integer not null unique, primary key (addressId));"
--
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
[Hibernate-JIRA] Created: (HHH-3299) Compatibility problem with jars
by Dean Hiller (JIRA)
Compatibility problem with jars
-------------------------------
Key: HHH-3299
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3299
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.6
Environment: version 3.2.6 core, 3.3.1 Annotations, 3.3.2 Entity Manager
Reporter: Dean Hiller
When I delete my asm.jar, I correctly get
org/objectweb/asm/CodeVisitor
java.lang.NoClassDefFoundError: org/objectweb/asm/CodeVisitor
The above proves I don't accidentally have another version on the class path.
Once I put the correct version of asm.jar from hibernate core back in, I get the following error....
[junit] org.objectweb.asm.ClassVisitor.visit(IILjava/lang/String;Ljava/lang/
String;[Ljava/lang/String;Ljava/lang/String;)V
[junit] java.lang.NoSuchMethodError: org.objectweb.asm.ClassVisitor.visit(II
Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;)V
[junit] at net.sf.cglib.core.ClassEmitter.begin_class(ClassEmitter.java:
77)
[junit] at net.sf.cglib.core.KeyFactory$Generator.generateClass(KeyFacto
ry.java:173)
[junit] at net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGe
neratorStrategy.java:25)
[junit] at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClass
Generator.java:216)
[junit] at net.sf.cglib.core.KeyFactory$Generator.create(KeyFactory.java
:145)
[junit] at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:117)
[junit] at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:108)
[junit] at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:104)
[junit] at net.sf.cglib.proxy.Enhancer.<clinit>(Enhancer.java:69)
[junit] at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.getProxyF
actory(CGLIBLazyInitializer.java:117)
[junit] at org.hibernate.proxy.pojo.cglib.CGLIBProxyFactory.postInstanti
ate(CGLIBProxyFactory.java:43)
[junit] at org.hibernate.tuple.entity.PojoEntityTuplizer.buildProxyFacto
ry(PojoEntityTuplizer.java:162)
[junit] at org.hibernate.tuple.entity.AbstractEntityTuplizer.<init>(Abst
ractEntityTuplizer.java:135)
[junit] at org.hibernate.tuple.entity.PojoEntityTuplizer.<init>(PojoEnti
tyTuplizer.java:55)
[junit] at org.hibernate.tuple.entity.EntityEntityModeToTuplizerMapping.
<init>(EntityEntityModeToTuplizerMapping.java:56)
[junit] at org.hibernate.tuple.entity.EntityMetamodel.<init>(EntityMetam
odel.java:302)
[junit] at org.hibernate.persister.entity.AbstractEntityPersister.<init>
(AbstractEntityPersister.java:434)
[junit] at org.hibernate.persister.entity.SingleTableEntityPersister.<in
it>(SingleTableEntityPersister.java:109)
[junit] at org.hibernate.persister.PersisterFactory.createClassPersister
(PersisterFactory.java:55)
[junit] at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryIm
pl.java:226)
[junit] at org.hibernate.cfg.Configuration.buildSessionFactory(Configura
tion.java:1300)
[junit] at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory
(AnnotationConfiguration.java:859)
[junit] at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory
(Ejb3Configuration.java:669)
[junit] at org.hibernate.ejb.HibernatePersistence.createEntityManagerFac
tory(HibernatePersistence.java:126)
[junit] at javax.persistence.Persistence.createEntityManagerFactory(Pers
istence.java:51)
[junit] at biz.xsoftware.rocketwar.server.test.AbstractHibTestCase.build
SessionFactory(AbstractHibTestCase.java:51)
[junit] at biz.xsoftware.rocketwar.server.test.AbstractHibTestCase.setUp
Impl(AbstractHibTestCase.java:67)
[junit] at biz.xsoftware.mock.testcase.MockTestCase.setUp(MockTestCase.j
ava:52)
[junit] at biz.xsoftware.mock.testcase.MockTestCase.runBare(MockTestCase
.java:112)
The manifest version of asm.jar is 1.5.3. The cglib is called cglib-2.1.3 but has not versoin in the manifest at all. I really don't know what is going on. Is it going through a special path of code that doesn't work and is a bug. I can't see how this can be user error right now since when I remove the asm.jar, I get classnotfound. It is interesting that the class not found is CodeVisitor while methodnot found is on Classvisitor. I am still looking into this but can't seem to figure out the bug completely.
--
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