I received the following error after upgrading from Hibernate 3.1 to Hibernate 3.1.1.

My application uses stateless session beans to retrieve POJO's from hibernate. Each method call involves opening a hibernate session, retrieving some data, closing the session and finally returning the POJO’s to the client.

I receive the error below during the marshall/unmarshall processing of returning a list of POJO’s on WebLogic 8.1.

The POJO's that are returned are retrieved using HQL. All many-to-one and bags are lazy loaded and are not retrieved in this query.

The object model is as follows.

A list of Labels.

Label contains a many-to-one relationship to NriApplication which contains a bag of FunctionKey.

I reverted back to Hibernate 3.1 and the methods began working correctly.

Arthur Fitt
arthur.fitt@netregulus.com


org.hibernate.SessionException: Session is closed!
at org.hibernate.impl.AbstractSessionImpl.errorIfClosed(AbstractSessionImpl.java:50)
at org.hibernate.impl.SessionImpl.getPersistenceContext(SessionImpl.java:1794)
at org.hibernate.proxy.BasicLazyInitializer.getReplacement(BasicLazyInitializer.java:100)
at org.hibernate.proxy.BasicLazyInitializer.invoke(BasicLazyInitializer.java:54)
at org.hibernate.proxy.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:156)
at com.netregulus.common.businessmodel.shared.NriApplication$$EnhancerByCGLIB$$aad3fbcb.writeReplace(<generated>)
at sun.reflect.GeneratedMethodAccessor140.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at java.io.ObjectStreamClass.invokeWriteReplace(ObjectStreamClass.java:896)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1011)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at java.util.ArrayList.writeObject(ArrayList.java:529)
at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:809)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1296)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at weblogic.rmi.internal.CBVOutputStream.writeObject(CBVOutputStream.java:78)
at weblogic.rmi.internal.ServerRequest.unmarshalReturn(ServerRequest.java:94)
at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:293)
at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:247)
at com.netregulus.bt.core.util.ReferenceDataProviderEJB_895xpq_EOImpl_814_WLStub.getLables(Unknown Source)
at com.netregulus.bt.core.util.ReferenceDataProviderEJBProxy.getLables(ReferenceDataProviderEJBProxy.java:168)
at com.netregulus.ui.core.cache.ReferenceDataCache.getLabelWrapper(ReferenceDataCache.java:750)
at com.netregulus.ui.core.cache.ReferenceDataCache.getLabel(ReferenceDataCache.java:776)
at com.netregulus.ui.core.cache.ReferenceDataCache.getLabel(ReferenceDataCache.java:783)
at com.netregulus.ui.core.util.ErrorPage.getLabel(ErrorPage.java:232)
at jsp_servlet.__errorpage._jspService(__errorpage.java:168)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:33)
at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1006)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:419)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:463)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:28)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
at com.netregulus.ui.core.filtersandlisteners.LoggingMDCFilter.doFilter(LoggingMDCFilter.java:60)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
at com.netregulus.ui.core.filtersandlisteners.NriUploadFilter.doFilter(NriUploadFilter.java:91)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:326)
at weblogic.servlet.internal.ServletResponseImpl.sendError(ServletResponseImpl.java:531)
at weblogic.servlet.internal.WebAppServletContext.handleException(WebAppServletContext.java:4056)
at weblogic.servlet.internal.WebAppServletContext.handleThrowableFromInvocation(WebAppServletContext.java:3834)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3780)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2644)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)

The error confirms what you say in design:

- Collections are lazy initialized.
- You are closing session before marshalling the object to client.

Once the session is closed, you can not explore uninitialized lazy collections anymore (a lazy initialized collection will gather it's content, using the session, only when required).

The error sudden appearance is probably a consequence of the following hibernate improvement in 3.1.1 changelog:


http://opensource2.atlassian.com/projects/hibernate/browse/HHH-1290

Solution: don't manipulate object outside session to avoid problem.

I'm not accessing the collection in my code. It is the marshalling processes, which I have no control over, that is acessing the lazy collection.

Arthur

Then close the session after the unmarshalling process, not before (using, for example, a session per request pattern).

I can't close the session after the marsalling process.The method is coded as below. A PersistenceManager is a wrapped hibernate session. This is a Stateless Session EJB method. It is the container marshalling the list of objects to return to the remote caller that is throwing the exception.

When you never need the relations you may consider to write your own serialisation methods for your object or declare your collection as transient. I "hope" that this could work.

Alternatively, intialyze your objects.

Sebastian

It's not that I never need them. I don't need them for this particular use-case. I don't want to initialize them because that will run extra queries for data I am not using.

For other use-cases I need the collections populated and call a different EJB method that does initialize that collection.

I don't understand why 3.1.1 forces you to have all colections initialized before serialization when 3.1 and 2.1 did not.

In this case I have selected the exact set of data needed for my use-case.

Try "factory.getCurrentSession()" and do not close session, transaction listener must close it.
http://www.hibernate.org/hib_docs/v3/re ... nt-session

if you can prove that we changed serialization behavior with a small test case then please submit to jira.

Yep, this is indeed a bug:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-1392

Has there been made any progress to this issue?

We have the same problem (Hibernate 3.1.3/Weblogic 9.2.1), see our log:



We have opened a call at the BEA support, but we just receive the following answer : "It appears to be a Hibernite issue.".

Can anyone confirm this serialization problem is a Hibernate issue?
Is it normal that the Weblogic serialization call the equals method on a lazy object?
If I look in the java code of the PersistentSet.java I see this :



So the call of the equals method (in the Weblogic Serialization process) will also read the lazy data, but I don't need this data. should the equals method be changed?

Thanks in advance for any remarks!

We have the same problem (Hibernate 3.1.3/Weblogic 9.2.1), see our log:



We have opened a call at the BEA support, but we just receive the following answer : "It appears to be a Hibernite issue.".

Can anyone confirm this serialization problem is a Hibernate issue?
Is it normal that the Weblogic serialization call the equals method on a lazy object?
If I look in the java code of the PersistentSet.java I see this :



So the call of the equals method (in the Weblogic Serialization process) will also read the lazy data, but I don't need this data. should the equals method be changed?

Thanks in advance for any remarks!