Hibernate version: 3.2 CR4
Name and version of the database you are using: MSSQL Server

I'm using WebSphere Application Server version 6.0.2.13
and I'm trying to migrate from Hibernate 2.1.8 to the latest 3.2.0 RC4

Everything seams ok except for the following strange problem:

I'm using Hibernate within an EJB and when I send a detached object retrieved with hibernate to the web container, it takes from 10 to 20 seconds.

I noticed that this long delay is caused by the copyObject method of the EJB stub:

return (List)Util.copyObject(result,_orb());


With Hibernate 2.1.8 it is working fine, the method is very fast.

What could be the reason of this long delay ? the object is too big ? may be it is not detached from the session ?
I tried to close the session and call the evict method to detach the object,
but there is no improvement.

I tried also Hibernate version 3.1.3 but the result is the same.

What could I try more ? Did anyone had a similar problem ?
Any suggestion will be appreciated
Thanks

We are experiencing what seems to be exactly the same problem. Have you found a solution yet?

We're using WebSphere 6.0.2.11 and Hibernate 3.1.3.

There is a servlet that calls an EJB. The EJB uses Hibernate to select a list of 2000 objects and returns those to the servlet.

The size of the list is about 1.4 MB but within the copyObject() method more than 500 MB are allocated and it takes about 20 seconds until the copyObject() method returns. After that everything seems to work fine.

The time and memory is spent between our EJB return and the method invocation in the servlet.

Any clues?

Thanks.

what does your copyObject do ? traverse all relationships ?

It is not exactly "our" copyObject() ... rather IBM's or Sun's.

When the EJB call returns to the calling servlet the generated WebSphere stubs do call


this in turn calls


and finally


This class is located inside the "ibmorb.jar" of the IBM JDK 1.4.2.

This copyObject(...) method is the place where all the time and the 500 MB are spent.

I assume this method does a "deep" copy of the object and is used to separate the object within the EJB and the returned object within the calling servlet to simulate a "remote call" within the same JVM.

We are still evaluating this, but it seems like the problem goes away, when we replace the PersistenSet and Maps inside of the object with standard HashSets and HashMaps.

Does anyone else use Hibernate inside of WebSphere 6 and calls EJBs from servlets?

why this is different when using Hibernate 2.x I have no explanation too. It is not our code that does the copying; but if the code has just blindly done a deep copy it would result in it fetching your whole database...no matter what version of hibernate you would use.

It turns out that the problem I described apparently does not have anything to do with Hibernate.

The memory and time consumption occurs when returning from an EJB to a servlet running in the same JVM but using the remote interface of the EJB instead of the local interface.

For the problem to manifest itself we do not need to use Hibernate but any sufficiently complex return object will do. The size in bytes is not really that important, what counts is the number of objects and attributes referencing each other.

We have found three workarounds:

1. Use a local interface for the call between servlet and EJB (which we cannot do at the moment because of "customer constraints" ;-).

2. Put the servlet and EJB in two different JVMs in the same WebSphere cluster and continue to use remote interfaces. Although this may seem strange, this actually avoids the performance problem since the "copyObject()" method is not used this way ...

3. Wrap our complex return object within a "transport object" that contains only a "byte[]" and serialize our return object into the byte[]. Return the transport object and deserialize on the client side.

Again, the problem is not caused by Hibernate itself ...

good - as expected ;)