[Hibernate-JIRA] Commented: (HHH-1786) JTASessionContext.CleanupSynch does not remove sessions from currentSessionMap
by Gary Sargent (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1786?page=c... ]
Gary Sargent commented on HHH-1786:
-----------------------------------
Having looked into this further, in JTASessionContext, the map is being populated with a different key to that used when it is being read (in the two places a get and a remove are performed on the Map).
This will work fine for non-Websphere transaction lookups as the default implementation returns the transaction, which is what is used for the get / remove.
For WebSphere, this won't work as this uses a different key. This means a new session is ALWAYS created even if one exists, and sessions are NEVER removed!
Solution is to ensure the correct key is used in the get and remove methods on the Map. Diff for JTASessionContext.java against 3.3.0 is:
104c104,107
< Session currentSession = ( Session ) currentSessionMap.get( txn );
---
> Object txnIdentifier = factory.getSettings().getTransactionManagerLookup() == null
> ? txn
> : factory.getSettings().getTransactionManagerLookup().getTransactionIdentifier( txn );
> Session currentSession = ( Session ) currentSessionMap.get( txnIdentifier );
110c113
< txn.registerSynchronization( buildCleanupSynch( txn ) );
---
> txn.registerSynchronization( buildCleanupSynch( txnIdentifier ) );
122,124d124
< Object txnIdentifier = factory.getSettings().getTransactionManagerLookup() == null
< ? txn
< : factory.getSettings().getTransactionManagerLookup().getTransactionIdentifier( txn );
131,132c131,132
< private CleanupSynch buildCleanupSynch(Transaction txn) {
< return new CleanupSynch( txn, this );
---
> private CleanupSynch buildCleanupSynch(Object txnIdentifier) {
> return new CleanupSynch( txnIdentifier, this );
183c183
< private Transaction txn;
---
> private Object txnIdentifier;
186,187c186,187
< public CleanupSynch(Transaction txn, JTASessionContext context) {
< this.txn = txn;
---
> public CleanupSynch(Object txnIdentifier, JTASessionContext context) {
> this.txnIdentifier = txnIdentifier;
201c201
< context.currentSessionMap.remove( txn );
---
> Object x = context.currentSessionMap.remove( txnIdentifier );
> 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
16 years, 4 months
[Hibernate-JIRA] Created: (HHH-3463) Make proxies truly Serializable
by Daniel Fernández (JIRA)
Make proxies truly Serializable
-------------------------------
Key: HHH-3463
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3463
Project: Hibernate3
Issue Type: Improvement
Components: core
Affects Versions: 3.2.6
Environment: Hibernate 3.2.6, database-independent
Reporter: Daniel Fernández
When I get a CGLIB entity proxy from hibernate, it is in an un-initialized state, but I can serialize it anyway... if I do, and then de-serialize it, by the moment I call any of its "getX()" methods, it tries to get initialized and... it fails with:
LazyInitializationException: could not initialize proxy - no Session
This is normal for me, but a little frustrating. Having a look at Hibernate's code, I found that org.hibernate.proxy.pojo.cglib.SerializableProxy had the following "readResolve" method:
private Object readResolve() {
try {
return CGLIBLazyInitializer.getProxy(
entityName,
persistentClass,
interfaces,
getIdentifierMethodName==null ?
null :
getIdentifierMethodClass.getDeclaredMethod(getIdentifierMethodName, null),
setIdentifierMethodName==null ?
null :
setIdentifierMethodClass.getDeclaredMethod(setIdentifierMethodName, setIdentifierMethodParams),
componentIdType,
id,
null // <-- SESSION
);
}
catch (NoSuchMethodException nsme) {
throw new HibernateException("could not create proxy for entity: " + entityName, nsme);
}
}
In which I can see that the last argument for that CGLIBLazyInitializer.getProxy call, which is the session, is null. Of course, that is why it fails telling that there is no Session from which to re-initialize the proxy... because the reconstructed proxy never gets one.
So here my point is: could it be possible to make proxies truly serializable by making them automatically retrieve a session when deserialized?
I understand that retrieving a session will first mean being able to know which session to retrieve, but maybe something like SessionFactory.getCurrentSession() would do for all people using some sort of "OpenSessionInView" pattern...
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
16 years, 4 months
[Hibernate-JIRA] Commented: (HHH-1786) JTASessionContext.CleanupSynch does not remove sessions from currentSessionMap
by Gary Sargent (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1786?page=c... ]
Gary Sargent commented on HHH-1786:
-----------------------------------
I've tested this with WebSphere V6.1.0.19 and Hibernate 3.3.0 SP1 (CMT and Oracle).
Sessions are still not being removed from currentSessionMap. I've added debug into JTASessionContext.CleanupSynch.afterCompletion(), and the remove from map method always returns null.
I notice in WebSphereExtendedJTATransactionLookup that the patch in this JIRA entry to cache the localId reference in getLocalId() is not present in the official release. Should this not have made it into 3.3.0 GA?
> 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
16 years, 4 months
[Hibernate-JIRA] Created: (EJB-380) Nested Join Criteria generates non-working SQL
by Ristretto (JIRA)
Nested Join Criteria generates non-working SQL
----------------------------------------------
Key: EJB-380
URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-380
Project: Hibernate Entity Manager
Issue Type: Bug
Environment: Hibernate version:
Core 3.2.6 GA
Annotations 3.3.1 GA
Entity Manager 3.3.2 GA
Name and version of the database you are using:
PostgreSQL 8.0.15
Reporter: Ristretto
Priority: Minor
A "org.postgresql.util.PSQLException: ERROR: table name "comp1x2_" specified more than once" exception is thrown when executing the following query using Criteria:
Criteria criteria = em.getSession().createCriteria(Customer.class);
criteria.createAlias("supplier", "supp1");
criteria.createAlias("supp1.company", "comp1");
criteria.add(Restrictions.eq("comp1.name", "Test Name"));
List<Customer> customers = criteria.list();
I have also tested the snippet of code with MySQL and obtained a similar MySQL exception. The generated sql statement is as follows (Supplier is the superclass of Partner and Provider and I'm using a Joined Table inheritance strategy) :
select [...] from Customer this_ inner join Supplier supp1x1_ on this_.supplierId=supp1x1_.id
left outer join Provider supp1x1_1_ on supp1x1_.id=supp1x1_1_.id
left outer join Partner supp1x1_2_ on supp1x1_.id=supp1x1_2_.id
inner join Company comp1x2_ on supp1x1_1_.companyId=comp1x2_.id
inner join Company comp1x2_ on supp1x1_2_.companyId=comp1x2_.id where comp1x2_.name=?
--
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 months