Hi all and Gavin,

I guess subjects around DTOs/DTOG(DTO-graph) has already been disucssed million times, however I could only find one topic on DTO explaining this abbreviation itself. So please allow me to ask this question again, go straight to be point and save time.

Ideal case would be the following: a SINGLE object-graph is passed back and forth among layers (presentation/business/hibernate) with each layer doing their own stuff in COMPLETE ignorance of the other layers: presentation layer shows objects; business layer calculates; hibernate layer saves and loads, opening and closing sessions as required.

If the SINGLE object-graph were a single object, hibernate is really ideal. However, if it is a graph, problems come.

Let's say you have a graph A with two objects only: A(i) and A(ii) and loading either one of them will cause the other to be loaded in hibernate (this can happen very frequently in hibernate usages)

step 1:
loads A(i) and from relationship we get A(ii) at the same time. Detach A and close the session.
step 2:
do some business stuff on A(i)
setp 3:
do some load/save of A(i) in a new session S
step 4:
do some business stuff on A(ii)
step 5:
do some load/save of A(ii) in THE SAME SESSION S.

Often, in step 5 you will get hibernate exception saying that the A(ii) object already loaded in session S.

This can be a big, general problem for programmers as no one can predict exactly when and which part of an object-graph needs to be persisted EVEN in a single user action (it is very likely that step 2 to 5 can happen in just one mouse click). Using a different session S' instead of S in step 5 can prevent the exception from showing up, but it is not a solution as it implies one open/close of session per save.

Is there a way out in theory? Or I'm just not experienced enough? I found this problem in 2.0.3, how about 2.1?

Thanks for your help!

Best,
Nick[/b]

Hi,

I am assuming if you are having problems with object already loaded exception you are trying to reassociate A(ii) via sesssion.update or session.lock. This problem is especially apparent in the approach to session management which I like to use which is to have a thread local session so that nested method calls all use the same session. In general the solution to this problem is to AVOID using session.update. Instead load the object from the database via session.load which will either get it from the session cache if it is already there or retrieve it from the database. Of course there is a performance penatly if the object has not been loaded because you will do a select and then an update. The other approach is to call session.evict on the object before calling update so that if even if the object is associated to the session you get rid of it.

Regards,

Yes, exactly what I mean. So you suggest using "evict" whenever I hit these exception. I'm just wondering whether there is a solution in theory. What is the obstacle that prevents the hibernate session from performing some kind of "merging" the two duplicates into one? Is this technically possible?

No.