Folks

I posting this to see if there is a quick fix to my problem.
Here it is...

We have an hibernate application(hibernate 2.03) running on iSeries vR52 using Websphere v5.1 and the native iSeries DB2 jdbc driver(via a Websphere V5 datasource) that appears to run fine until we have a network problem. At the point of a network issue (i.e. TCP/IP server rests itself) the application appears to cause Websphere to go into a loop and chew the CPU up.

When all the logs(iSeries dumps and JVM dumps) are examined it would
appear that the job eating the cpu up is a HASHMAP.GET. below is dump from the JVM

java/util/HashMap.get
net/sf/hibernate/impl/SessionImpl.getEntity
net/sf/hibernate/loader/Loader.getRow
net/sf/hibernate/loader/Loader.doFind
net/sf/hibernate/loader/Loader.find
net/sf/hibernate/hql/QueryTranslator.find
net/sf/hibernate/impl/SessionImpl.find
net/sf/hibernate/impl/SessionImpl.find
net/sf/hibernate/impl/SessionImpl.find
uk/co/ltf/ltas/custinter/actions/SlaMonitorAction.slaSCCandASEnquiry
uk/co/ltf/ltas/custinter/actions/SlaMonitorAction.execute

This takes all the CPU up and the only way to stop it is bring websphere down and restart everything. This only happens if we have a network problem and runs fine till then.

What I would really like to know is -
1) is this a problem that you/anyone is/are aware of?
2) would upgrading to Hibernate 2.1.1 eradicate the problem?
3) we do not use any HashMaps in the application at all so I assume that the HashMap.get must be internal to Hibernate.
4) I know we have to resolve our network issues but I am at a aloss as why this would happen.

I can provide further information if required but to save typing loads more info I thought I would get this posted ASAP.

thanks in advance for any information

Do you use the WAS connection pool with some connection recovery feature (should have one) ?

Thanks for the reply

Below are the settings we have set for the datasource win WAS5.0.2

This is how the Connection Pool settings for jdbc/localdb2:

Connection Timeout: 1800 seconds - Interval, in seconds, after which a connection request times out and a ConnectionWaitTimeoutException is thrown.
Max Connections: 25 connections - The maximum number of ManagedConnections that can be created in this pool.
Min Connections: 1 connections - The minimum number of ManagedConnections that should be maintained.
Reap Time: 180 seconds - Interval, in seconds, between runs of the pool maintenance thread.
Unused Timeout: 1800 seconds - Interval, in seconds, after which an unused connection is discarded by the pool maintenance thread.
Aged Timeout: 0 seconds - Interval, in seconds, after which an unused, aged connection is discarded (regardless of recent usage activity) by the pool maintenance thread.
Purge Policy: EntirePool

Is this what you mean?

How would this cause a the problem we seem to be having

Many thanks
Paul

Well I don't know WAS, but most connection pooling has a festure allozing to check the connection from ti;e to time and rebuid it if it fails.
I don't see any obvious link with Hibernate. Did you change your driver? Try to upgrade/change it to see what happen ?

Thanks Emmanuel for your replies

We have tried two up-to-date drivers, but it would appear that we have the same problem.

The powers that be at a large blue corporation have analysed loads of reports and have hinted at the problem being down to hibernate using low level sockets and that it can't handle network failures.

Does hibernate use low level sockets?

I have to admit that this is out of my area of expertise, but I felt I needed to ask the question.

Can you/anyone throw any light on this?

thanks once again in advance.

No, of course not - Hibernate just uses the appserver connection pool like any other JDBC client.



Whoever is giving you advice is smoking a large blue crack pipe.

Gavin

That is exactly what I thought.

Thank you very much for confirming that.

:)