I think your misunderstanding the issue. My application is working fine, no lazy init issues etc. I call merge because I *want* things persisted to the DB. I mentioned the lazy init exception because that is what happens if you clear the hibernate session (and spring will do it if it rolls back a transaction).
Here is the blog post with a concrete example: http://stronglytypedblog.blogspot.com/2009/03/wicket-patterns-and-pitfalls-3.html I only sent the email as another option for the Session flushing that happens when a transaction (or nested transaction) is committed. -Ryan On Fri, Jun 19, 2009 at 11:45:42AM +0530, vineet semwal exclaimed: >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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
