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: [email protected] For additional commands, e-mail: [email protected]
