A similar scenario applies when using Wicket with JDO. You can use simple LDM when dealing with read only model objects. However, when you deal with model objects that are the subject of modification in a form you need to use JDO's detach/reattach mechanism which allows the form elements to keep references to serializable, detachable (and reattachable) copies of the object(s) being modified. This means all changes the user makes to the model objects are preserved across multiple HTTP requests (AJAX or opening new panels in a wizard style form) but not written to the DB.
It's important to note (and this applies to any ORM that supports detach/attach) that the detach/attach cycle for objects being modified are not the same times as a typical LDM detach/attach (i.e. typically with the http request cycle). It's also important to note that Wicket 'detach' is not the same as ORM 'detach' although you can perform an ORM detach inside a wicket detach method. When setting up an object for modification you load the objects required by the form and then perform a single detach so the object has a persistent ID but it no longer attached to the PersistenceManager(JDO) or Session(Hibernate/JPA). As many http requests can come and go as you like but until the user clicks OK or Submit on the form there should be no more ORM detaches or attaches peformed. Clicking Ok or Submit in the form performs a reattach and then you commit your transaction. It is at this point that any OptimisticVerificationExceptions will be raised if an object the user was editing was changed by another user or another process so you need to wrap this 'commit' inside an appropriate try/catch and warn the user (eg., with a modal form) that an object they were modifying had been modified by another user. JDO manages all the detach/attach for you. I just wrap the detach/attach in a custom IModel. "Back in my day we didn't need Wicket, Tapestry, JSF or WebObjects, or even Servlets, or for that matter Java! We just coded in plain assembly language. And before that we had to just type in 1's and 0's. Sometimes we didn't even have 1's. I once had to code for an entire month, barefoot, in the dead of winter, using just 0's... but you didn't hear me complaining." > -----Original Message----- > From: Martijn Dashorst [mailto:[email protected]] > Sent: Wednesday, 28 November 2012 11:19 PM > To: [email protected] > Subject: Re: How important is detaching models really ? > > On Wed, Nov 28, 2012 at 8:28 AM, Marios Skounakis <[email protected]> > wrote: > > 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? > > From the good old days: > http://martijndashorst.com/blog/2006/02/13/wicket-goodie-hibernate- > versioned-form/ > > Martijn > > --------------------------------------------------------------------- > 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]
