To All:

I am brand new to this list, but have used hibernate coupled with spring in several enterprise apps. Please point me in the right direction if I have posted to the wrong forum.

We have developed a new web application utilizing spring/hibernate and deployed to a JBoss app server (backended by an Oracle9i database). We are using Spring OpenSessionInViewFilter to keep a session open through rendering the jsp (for lazy loading purposes).

When we went live, (peak usage: 400 request per minute) we started getting exceptions that were caused by lack of avaialbe connections in the pool. We have stepped up the number of available connections, even to 100, but this problem persists.

We have spent 2 weeks trouble-shooting this issue and have come up with nothing. I have downloaded src for both spring and hibernate and this is my hunch:

A session is opened through the OpenSessionInViewFilter when a request comes in, when the first database request is made, a connection is opened. This connection persists with the sessoin object until the end for the request cycle, when it is then closed. So as multiple requests are made, multiple sessions are created, and connections bound to them to the life, and perhaps beyond the life of the request.

Am I mistaken? What can I do to solve this problem?

Any help, would be greatly apprecieated!

Thanks

Cardwell Cupp



Hibernate version: 2.1

Name and version of the database you are using:Oracle

Not really sure what you are asking here.

The Hibernate session will maintain a reference to the connection it obtains from the Datasource until it is either closed or disconnected.

Whether this can "leak beyond a request boundary" depends on what that filter is doing. Does it alwasy close the session in a finally block whose try block contains the filter.doChain() call?

Certainly each concurrent request will open its own session. How else would this work?

The thing you need to find out is whether the pool is being depleted over a series of sequential requests (i.e., there really is a connection leak somewhere) or across a series of concurrent requests (in which case you are either opening too many sessions or have too small of a connection pool).

Thanks for your repsonse!

>>The Hibernate session will maintain a reference to the connection it obtains from the >>Datasource until it is either closed or disconnected.

Right, I saw that the SessionImp doesn't explicitly call close on the connection, but relys on a couple of utility classes to do it. At any rate, I hacked a bit of the SessionImpl to explicitly close the connection when session.close() is called. We still run into the same problem, which is we can't keep enough connections in the pool.


>>Whether this can "leak beyond a request boundary" depends on what that filter is doing. >>Does it alwasy close the session in a finally block whose try block contains the
>>filter.doChain() call?

The answer is yes, I have overloaded the OpenSessionInViewFilter supplied by spring to explicitly close the connection. Since we rely completely on spring to manage hibernate sessions, it is hard for me to tell that we have a leak, and where it would be.

>> Understood, each request opens a session.
Certainly each concurrent request will open its own session. How else would this work?

>>The thing you need to find out is whether the pool is being depleted over a series of >>sequential requests (i.e., there really is a connection leak somewhere) or across a >>series of concurrent requests (in which case you are either opening too many >>sessions or have too small of a connection pool).

I am thinking that it is probably the latter of the two supplied problems. LIke I said earlier, since I am relying on springs openinviewsession to manage my session, a memeory leak seems to be less a possiblity. BUT, it doesn't mean it isn't possible. Is there a way to close the connection after each transaction, using the same session?


Thanks
Cardwell Cupp

Update: Configuration sucks.

Here is the thing, connection pooling is the culprit. It could be lack of experience on my part (which is completely possible), but after trying numerous things, we finally used DBCP for our connection pooling and guess what, it worked.

We removed the max wait setting, and bam, it performed. It actually had little or no wait time and only used approximately 8 out of the 20 we allocated the connections.

Thanks to all!

Cardwell Cupp