lazy initialization exception happens whens you try to initialize a object (generally collection) and hibernate session is already closed. merge is not recommended ,it attaches a object back to hibernate session + also cause database update( why will you update a object when you actually need to read a collection also what are the chances that it won't give you the same lazy initialized exception again as hibernate session can be closed before you try to access the collection.)
Simple solutions 1) eager fetch the collection if it's small. 2)For a big collection, write a method in data access layer that retrieves collection/association( initialize the collection this time). you can also do database paging in this case. regards, vineet semwal On Fri, Jun 19, 2009 at 11:13 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 > >
