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
