Hi Colin, I find I am in agreement with your points about lazy loaded parts of the data model and how this can be simplified if you use LDMs.
However, if you use LDMs for edit pages, you need to deal with concurrency issues yourself. You cannot rely on Hibernate's optimistic concurrency mechanism (version). Because every time your LDM fetches a fresh instance of the entity, you can never have a StaleObjectException. Dealing with concurrency yourself may be as easy as keeping the version property in addition to the Id property in the LDM, and checking against it when re-attaching the model, but this does add some complexity to the application code. Any thoughts on this? Cheers Marios On Wed, Nov 28, 2012 at 2:10 AM, Colin Rogers < [email protected]> wrote: > Tobias, > > I also find it's really important when using Hibernate. Hibernate is a > total dog unless all your fetches are Lazy (so you only load what you > need). With any UI, you load your entity and display a certain amount, but > based on user action, you might need lazy loaded dependencies - with a > loadable detachable model, the main entity is always 'fresh' in the session > and lazily loaded dependencies are always available. It means everything in > your data can be specified to be lazy loaded. Your data model is clean, > your UI is clean. > > In other UIs frameworks, or when I've used Wicket without LDMs, I spend > half my time dealing with Lazy Load Exceptions, or having to pre-load > certain lazy loaded entities for certain screens, that may or may not ever > be used. You end up changing your data model to fit your UI (ugh!) or > having tons of duplicated, effectively redundant, UI specific service > methods (ugh!). > > Cheers, > Col. > > -----Original Message----- > From: Chris Colman [mailto:[email protected]] > Sent: Friday, 23 November 2012 12:53 AM > To: [email protected] > Subject: RE: How important is detaching models really ? > > I guess in more complex apps the UI elements end up with lots of > references to model objects so detaching does save a lot of memory and it > also makes transferring session data from one web server to another (if > required) in a multi server environment, much more efficient. I have > experienced the result of accidentally serializing an object graph with > megabytes of data that didn't use detach - ouch! > > The other benefit of detaching is your model will expose updates to the UI > (if a redisplay occurred) that were made in other ORM sessions (depending > on your ORM). Keeping a non detached copy of the model object will > typically be like caching it in it's current state for most ORMs - i.e. it > can get stale > > >-----Original Message----- > >From: tobi [mailto:[email protected]] > >Sent: Thursday, 22 November 2012 9:10 PM > >To: [email protected] > >Subject: How important is detaching models really ? > > > >Hi guys, > > > > From my understanding & experiments with Wicket's built-in session > >inspector , detaching models seems to just affect the size of the page > >store (and of course cut-down the amount of I/O required for > serializing > >the object graph). The session size shown on my pages is a constantly > >low value (<1k , we're storing nothing except the currently logged-in > >user). > > > >So it *seems* not detaching models has no effect on the (long-term) > >memory footprint of a Wicket application. > > > >According to > >https://cwiki.apache.org/WICKET/working-with-wicket-models.html , not > >detaching models should affect the session size but at least looking at > >the inspector I can't see this. Is the wiki article still correct / the > >inspector not telling the truth ? > > > >Thanks, > >Tobias > > > >P.S. I'm using Wicket 1.5.8 btw > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [email protected] > >For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > EMAIL DISCLAIMER This email message and its attachments are confidential > and may also contain copyright or privileged material. If you are not the > intended recipient, you may not forward the email or disclose or use the > information contained in it. If you have received this email message in > error, please advise the sender immediately by replying to this email and > delete the message and any associated attachments. Any views, opinions, > conclusions, advice or statements expressed in this email message are those > of the individual sender and should not be relied upon as the considered > view, opinion, conclusions, advice or statement of this company except > where the sender expressly, and with authority, states them to be the > considered view, opinion, conclusions, advice or statement of this company. > Every care is taken but we recommend that you scan any attachments for > viruses. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
