Dear All,

I have a problem with multiple instances of the same pojo being attached to different session. Anyway, the problem is not relevent, what I'd like to do is to keep a single session open for a long(ish) time and just close/reopen the database connection within it each time I need to do some work with it. The connections are in a pool, so basically - I just loose the problem of tieing up connections with long-lived sessions. This would make my life a whole lot easier Let me try to explain:

I won't go into the details, but basically I found myself wanting to keep a cache of all open pojos that persist between operating cycles (this is a web app so by cycles I mean https request/response cycles). I'm useing the openSessionInView pattern so I can just add some code to the beginning of the new session that reattaches all the cached pojos (with lock). This means that next time I load up some objects, it'll reuse the reference that's already there and should avoid my nasty multiple pojo problem entirely.

However I started asking myself, "why am I basically wrapping the session up in a cache, when it's already got a cache built in? Oh yeah, because everyone says it's bad to keep a session open because it hogs resources. What resources exactly? Mmm, the database connection". This makes me think that perhaps a 'session' should be split into two objects - one for the cache and one for the 'connection.' Not wanting to rewrite an otherwise excellent library, I wondered if there was a way do this currently...

Does anyone know how to reopen a session with a fresh database connection?

Thanks,

Ben.

Ben,

I think you want the session-per-conversation pattern. There is some information here:
http://www.hibernate.org/hib_docs/v3/re ... sics-apptx
http://www.hibernate.org/hib_docs/v3/re ... ongsession

Also, see the hibernate.connection.release_mode configuration property and javadocs on session.disconnect() and session.reconnect() <== I think this one is the key for you.

I've never done this personally, but it does interest me. Post a reply once you get this working.

Hi Ben,

One this to clarify about the Session is that its only caches POJOs within the scope of the current transaction/request. Once the transaction is committed, the session is destroyed along with the cache. One of the goals of the session cache, or level 1 cache, is to avoid repeated reads of the same data in a given transaction. This cache is the "resources" people are referring to. Since the cache is scoped to a single request/response, you can see how poorly this will perform with concurrent requests if the memory is not reclaimed.

If you want to have the cached object span multiple requests, you have two options:

1.) Use a second level cache:

http://www.hibernate.org/hib_docs/v3/re ... ance-cache

The difference here is that the L2 Cache is available at the session factory level. So if User A and User B go after the same row of data, they'll be pulling it form the same cache, and not two distinct caches scoped to their respective sessions.

2.) Use an extended session as Ananasi had mentioned. If you're using JBoss Seam and/or EJB3 Session Beans, this can be done quite nicely:

http://docs.jboss.com/seam/1.2.1.GA/ref ... tence.html

Basically, what this approach does for you is keep a Session active until you say the "conversation" is over. Even if you don't use Seam, section 8.3.3 describe the functionality.

Ryan-

Ananasi & Damnhandy,

Thanks a million guys - that session-per-conversation pattern looks pretty much perfect. I was about to try and inplement this solution myself, so It's good to know I thinking in the right direction. Any tips on how to implement this pattern in a threadsafe way?

Thanks again,

Ben.