-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 18 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Loading lazy collection on *modified* detached instance
PostPosted: Wed Jun 08, 2005 9:49 pm 
Newbie

Joined: Wed Jun 08, 2005 7:30 pm
Posts: 1
Despite the rather religious Open Session in View discusssion, which I realy would like to avoid, I do want to re-open this discussion with one additional variation. In particular, this case involves using Hibernate in a Struts, multi-page, wizard-like scenario.

THE SCENARIO: Sticking with the example used above, the first step would involve loading the base Order object, leaving the (potentially very, very large) items collection to be loaded, if needed, at a later time. The first page is drawn via JSP with some basic fields like description displayed for updating.

In one use case, the user can save or cancel at this point, fulfilling the desire of perhaps only updating the description and by-passing any changes to the items ordered, thereby avoiding a really expensive call to load the items collection. Basic old update() or not here.

However, in use case two, the user would click thru to step two for altering the items, at which point in time the items collection needs to be loaded.

THE ISSUE: In Struts, while using the domain object itself for storing the information, the change in description is done and the detached domain object is "dirty", however, the user still has the option to abort all changes with no updates to the database. Hibernate then, won't let me lock the instance to retrieve the lazy collection. It will let me update() (prematurely by the use case), but at that point, there is no way for the user to abort and revert back to an untouched view.

THE QUESTION: I've tried various lock() LockMode's but get the message that the object has a dirty collection or end up with DB locking issues. So...how do I accomplish this wizardy behavior in Struts/Hibernate without creating a duplicate of the domain object and shuffling data in and out programmatically? I realize there are transactional issues here, but isn't that what the version is for?!? In this case, all versions counters would still be the same by the data, right? So what's the issue?


Top
 Profile  
 
 Post subject: Dependency (bad) in terms of error processing
PostPosted: Thu Nov 16, 2006 9:43 am 
Newbie

Joined: Tue Apr 18, 2006 4:54 am
Posts: 9
On the whole, I believe that this strategy (of using some sort of interceptor) is a Good Thing if you look at it as a System Resources type function.

In the web app scenario where this is implemented as, say, a Servlet Filter , it does mean that the error handling related to the transaction commit or rollback is done not in a data layer, but above the presentation layer (after the JSP has been rendered.

Is that not a Bad Thing?


Top
 Profile  
 
 Post subject: Re:
PostPosted: Mon Jun 07, 2010 3:08 pm 
Newbie

Joined: Fri Nov 17, 2006 11:32 am
Posts: 13
christian wrote:
Woah, the fourth question about this in two days. Is there some new tutorial somewhere? Here is what I said earlier:

Keep the Session open for one request, close it when all business logic in that thread has been executed. This is the common pattern, see:

http://www.hibernate.org/168.html



Link is broken

_________________
Neuquino
"Keep on trying and get better every day" (Queen)


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 18 posts ]  Go to page Previous  1, 2

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.