map a form to a bean and apply the changes to the entity yourself or do all validation via I(Form)Validators
-igor On Wed, Jun 25, 2008 at 8:51 AM, cretzel <[EMAIL PROTECTED]> wrote: > > Hi, > > I'm using Wicket together with Spring and Hibernate. And it's quite common, > I think, to use an OpenSessionInViewFilter and a LoadableDetachableModel > which wraps the domain objects loaded with Hibernate, so that when the model > is detached it only holds the ID of the domain object and when its > load()-method is called it uses the ID to load the entity again from the > database (see > http://www.nabble.com/How-to-avoid-Lazy-loading-exception-td17040941.html#a17041351 > this post for an example). So one advantage of this pattern is that you > mainly never get into problems with detached entities > (LazyInitializingException and so on). > > I only got one issue with this when using Spring's transaction support. > Suppose you are editing a domain object in a form and you submit the form > and it passes conversion and validation. Actually the changes you've made > have been written into the domain object when you are in onSubmit() for > example. Then in this situation these changes could easily get persistet to > the DB, even if you don't want them to at this point, e.g. because you want > to do some backend validation first. This can happen when Hibernate flushes > the session, for example before another query. The problem is that the > changes on the domain object are made outside of a transaction > [OpenSessionInViewFilter just opens a Session but doesn't start a > transaction]. > > An example: > Suppose you are editing an entity User, changing the username for example. > The onSubmit()-method could look like this: > > onSubmit() { > // User with changed username, attached to the Session > User user = (User) getModelObject(); > // Do a query. This will cause the changes made to user > // to be flushed to the DB > userService.getUsers(); > // This method does some backend validation, possibly > // fails and the transaction is rolled back so that the > // changes should not be persisted > userService.saveUser(user); > } > > After this, the changes could be persistent in the DB, although they > shouldn't because the validation in the backend failed which should have > rolled back the changes. > > I hope I made clear the point. > > What do you think? > > -- > View this message in context: > http://www.nabble.com/OpenSessionInView-%28OSIV%29%2C-LoadableDetachableModel-and-Transactions-tp18115802p18115802.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > 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]
