The only changes that will be persisted to the database are ones that go on within a transaction. So, do all of your work in transactional methods (in spring-managed beans), but leave your session open for the entire request so that you can traverse relationships if necessary.
On Fri, Jun 19, 2009 at 1:43 AM, Ryan <wicket-us...@mandrake.us> wrote: > > I have been reading Nick Wiedenbrueck's blog, specifically about > patterns and pitfalls when using wicket with spring and hibernate. > > It seems fairly common for programmers to run into the "issue" of having > entities persisted to the database at unexpected times. This happens > when a transaction is closed and the hibernate session is flushed. > Certainly this issue is not specific to using Wicket with spring and > hibernate, but I think it is common enough to warrant some attention. > > There are a few suggestions to solving this problem: > > 1) Use DTOs > 2) Make sure validation happens in wicket so the object is not modified > 3) Clear the hibernate session or throw exceptions at just the right > times > > I think all of these have some issues. Using DTOs is code heavy. > Validating entirely in wicket is not always an option (sometimes the > service tier needs to do some extended business validation). Clearing > the hibernate session or throwing exceptions will cause Lazy > Initialization exceptions if not used carefully (which can be hard when > you do not control all the components on a page) > > I wanted to share one solution I have used and see what others think. > > I mark all of my transactional methods (usually in the service) as read > only. I then define a set of "persist" methods (usually on a DAO) that > are marked as REQUIRES_NEW and are not read only. When I am ready to > persist an object it is passed to one of these methods and merged into > the session. This effectively persists the object. Some of these persist > methods can take a collection of objects so that they can be persisted > efficiently in one transaction. So far this has worked well for me. > > Does anyone have any thoughts on this method or can share some other > techniques? > > Thanks, > Ryan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
