Mark your transactional method that does validation as readOnly=true On Fri, Jun 19, 2009 at 2:02 PM, Ryan<wicket-us...@mandrake.us> wrote: > Consider this use case: > > 1) User object is read from hibernate, either in a transaction or not > 2) User is modified via wicket, and passed wicket's validation > 3) User is sent to service tier for further validation, this service is > marked as propagation required > 4) Validation fails, or for some reason the user should not be > persisted. At this point a number of things can happen: > > a. Throw exception, which clears the hibernate session and rolls back > b. manually call session.clear on the hibernate session > c. Let the method finish, perhaps returning false. This will auto > commit the transaction and the user is persisted. > > It gets even more tricky if Wicket also read another entity from > hibernate and modified it, but it was not ready to be persisted to the > db. When the transactional service method is called on the user object, > it will commit and flush *any* modified objects loaded in the hibernate > session. > > My setup adds another option to the list. Since all the transactions > are readonly, the service tier must call a specific dao method that is > marked as read-write and requires_new. This creates a new hibernate > session which merges *only* the object passed into the method. > > It all comes down to handling detached objects or long hibernate > sessions. It is by no means a new issue, but I think it can confuse > first time users of LDMs. > > -Ryan > > On Fri, Jun 19, 2009 at 06:30:14AM -0400, James Carman exclaimed: > >>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 >> > > --------------------------------------------------------------------- > 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
