Dear All,

I have a problem reattaching pojos across multiple sessions. These pojos are value objects - like Money or Long - in that their value is more important than the reference. Two separate instances of the pojos are equal if they have the same value... I think the code speaks for itself...



I want to reattach this second pojo before I start using it so that I have the most recent data. This is also necessary for any LazyInitialised Collections held within it. Lock doesn't work because it uses the IdentityMap inside the session during the first half of the process, which doesn't find the existing equivalent pojo already there. Then the second half of the process tries to save the second pojo - only to find the other one sitting in the session and throwing an error.

I can't really use Merge as I can't replace the pojo2 reference (it's held in other objects...) and I can't just use one session as the different steps span web-requests...

Any clues? This problem is causing me significant headaches. I just want a refresh function that fixes references to the persistent session so that my Lazy Initialisation works, and merges any changes in data. This doesn't sound too much to ask for, does it?

How do i do that?

Regards,

Ben.[/code]

You can:



Anyway you look at it, Hibernate isn't going to go out through your application and update all the references to this or any other entity that are not managed by this particular session (session3). Hibernate doesn't have any knowledge of detached or transient instances. So, if you want to avoid overwriting a change to this entity, you will have to refresh(pojoX) to get the database contents. Otherwise, you can look at versioning.

Kerstetter,

Hi there, and thanks for you input. I don't expect Hibernate to locate detached pojos for me and update them, but I would like it to update two copies, or rather clones, of the same pojo (essentially the same, just a different object ref identity) when I ask it to.

Merge is very neary enough, except that it returns the newly merged pojo rather than updating the reference you gave it. This is a problem for me, as the reference will be tucked away in the system, somewhere, probably in multiple places. I just want to to get/set any values that have updated sinse it was originally loaded and to reattach any lazy collections with the new session so that they will work.

Can you help?

OK, going back to your original code snippet:

Kerstetter,

Thanks for your help with this. I've implemented your suggested eviction/refresh idea in an error handler so that it tries to do a simple lock first, and if there is a problem, it bumps the old version out and refreshes the new one. This should work as a final line of defence but is a bit ugly - I'm worried I'm going to have two versions of the same object floating around that I think are simple references to each other but are actually independant. so I started trying to engineer around the problem.

I won't go into the details, but basically I found myself wanting to keep a cache of all open pojos that persists between 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. This means that next time I load up some objects, it'll reuse the reference that's already there and should avoid the whole problem entirely (although I'm still going to use your nifty evict/refresh pattern as a last resort).

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 of 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.' Then I wondered if you could do this anyway...

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

Thanks,

Ben.

Kerstetter,

Just to let you know I've had a solution to this problem already. There's another Hibernate pattern called Session-per-conversatio which does exactly what I described - you keep your session open longer and close() just frees up the database conection. When you next use the session it fetches a new connection from the pool and lets you carry on. It's perfect.

I've just got to figure out a way to limit the size of the session cache so I don't crash the server too often - and find a way to make the session threadsafe.

Cheers,

Ben.