I'd say either enable transactions only for write operations or put all together in one transaction (i.e. don't let hibernate flush the session before you did your backend checks) ...
cretzel 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? > > ----- Michael Sparer http://talk-on-tech.blogspot.com -- View this message in context: http://www.nabble.com/OpenSessionInView-%28OSIV%29%2C-LoadableDetachableModel-and-Transactions-tp18115802p18115882.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]
