Hi.

Our application follows session-per-request-with-detached object pattern for application transactions and we have a problem with the re-association of the detached object.

That is, during the first request, the user adds a new element (BusinessHours) to the parent object (Hotline), which then becomes detached. After a new child element is added, a businessHoursSet collection whithin the hotline becomes dirty, therefore we have to use session.update(...) to reassociate the hotline with the new session in a second request.

However, during this update, elements of the businessHoursSet are not updated but saveOrUpdated. Consequently, all new elements of businessHoursSet are saved, which is not desired.

My question is: how do I correctly reassociate detached objects having dirty collections with a new session?

Why does update cascades to saveOrUpdate in child collections? I mean specifically the following code in SessionImpl:



May be I miss something, but should it not be something like Cascades.ACTION_UPDATE instead of SAVE_UPDATE?

Your help is greately appreciated.

Hotline might be assumed as an object with id (long, -1 means new object) and businessHoursSet (a set of BusinessHours objects).

BusinessHours imight be assumed to be a simple object with long id (-1 means new).

Mapping is something like:

Sorry for bumping this - any help would be greately appreciated.

I hope the question is fine formulated - otherwise please let me know were could I be more clear. This is a major issue for us since right now we have to give up lazy collections, which destorys the performance.

Thank you in advance.

Your problem makes no sense. Why would you *not* want new elements to be saved??

Because it is not the correct time from the application flow point of view. I have a long application transaction spanning several requests which may (but also may not) lead to saving the parent object (in this case - a hotline) into the database. Objects should be saved only when user desires to save them, not because of the reassociation of a detached object.

I want to use session.update(...) *only* to reassociate a detached object with a new Hibernate session (primary goal is that lazy collections or proxies could be accessed). Saving new elements in collections is an undesired side effect and I have no idea how could I avoid it.

A similar problem was discussed in another topic - however no good answer.

http://forum.hibernate.org/viewtopic.php?t=928481&start=0&postdays=0&postorder=asc

Thank you for your time.

So don't flush the session at the end of that transaction.

This seems like a trivial problem??

Actually, let me qualify that slightly: either

(1) disable cascade on that association, and flush on that transaction OR
(2) disable flush and use a long session

The problem is that session.update(hotline) cascades to session.saveOrUpdate(businessHours). And saveOrUpdate assigns a new identifier to the new businessHours object. And when the session is finally flushed, Hibernate issues an UPDATE statement for a *new* object, not the INSERT statement, since this new object is already assigned an id.

select-before-update="true" on BusinessHours object does not help either.

Do you think it is correct to save new objects when reassociating a detached structure? I think it's not.

See my qualification.

Personally I use long sessions in this kind of scenario.

Thank you.

Long sessions are, unfortunatelly, not an option: we may not block concurrent requests from the same user, we do not know exactly when application transactions start and end.

Disable cascade on association - well, this is an option, but it isn't nice. Actually, the association should be cascaded.

What happens during reassociation with session.update() is not 100% correct from my point of view. Ideal would be a session.reassociate(...) method, which would reassociate objects (including proxies) and persistent collections (including "lazy") with the current session.

It seems like at the moment I'll have to avoid detached objects with lazy properties - either make properties non-lazy or initialize required properties before detaching.

I will also try implementing reassociate(...) method. I hope I'll opnly need to replace the cascading operation of the doUpdate(...).

There is session.lock(obj, LockMode.NONE)

... which is for unchanged objects only. If user adds new business hours to the hotline, session.lock(..) would produce "reassociating a dirty collection" exception.

Sorry.