tag:blogger.com,1999:blog-8976990577786961583.post7316370940107094927..comments2023-12-21T17:09:42.587+01:00Comments on Strongly Typed, Loosely Coupled: Wicket Patterns and Pitfalls #3Nick Wiedenbrückhttp://www.blogger.com/profile/08284848227891035967noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-8976990577786961583.post-45998236613189180692009-11-01T12:15:22.563+01:002009-11-01T12:15:22.563+01:00@Transactional(rollbackFor=Exception.class) will s...@Transactional(<b>rollbackFor=Exception.class</b>) will solve the problem; the update will be rolled back when the <i>DuplicateUsernameException</i> is thrown.Unknownhttps://www.blogger.com/profile/15465730188966735056noreply@blogger.comtag:blogger.com,1999:blog-8976990577786961583.post-58319597384784876172009-06-19T07:26:40.212+02:002009-06-19T07:26:40.212+02:00session.clear() will cause some problems as well.....session.clear() will cause some problems as well... for one thing you will get LazyInit exceptions for anything called after the clear. One technique I've used, and I am not sure if it is the best way, is to make all my transactions read-only using Spring. Then you either have a SaveDAO or save methods in your daos that are marked as "REQUIRES_NEW" transaction and are not read only.Ryannoreply@blogger.comtag:blogger.com,1999:blog-8976990577786961583.post-72713628712557055492009-03-27T09:48:00.000+01:002009-03-27T09:48:00.000+01:00I think the right thing (even if boring to manage)...I think the right thing (even if boring to manage) is to use a DTO, because the object edited in the form should NOT be an entity until validation occurs. More code to write but less problems, easier to understand and clean logic.<BR><BR/>Another way, could be (but I never tried it) call session.clear() when validation detects errors, so to clear pending changes (javadoc:"Completely clear the Garidanhttps://www.blogger.com/profile/00930735309664167951noreply@blogger.comtag:blogger.com,1999:blog-8976990577786961583.post-19143580868328346332009-03-27T08:41:00.000+01:002009-03-27T08:41:00.000+01:00@michel: That's right, the problem really isn't sp...@michel: That's right, the problem really isn't special only to Wicket, but it also appears with other web frameworks, that support OSIV and have some kind of variation of the LDM.<BR/><BR/>Your suggestion implies, that your solution does not use a LDM, or any Model to whicht the username input field is bound. But that's really one of the strengths of wicket. But anyway, your example would be a Nick Wiedenbrückhttps://www.blogger.com/profile/08284848227891035967noreply@blogger.comtag:blogger.com,1999:blog-8976990577786961583.post-84732968857701872682009-03-27T08:06:00.000+01:002009-03-27T08:06:00.000+01:00I think this Problem is not special to wicket.I th...I think this Problem is not special to wicket.<BR/><BR/>I think the better solution looks like:<BR/><BR/>@Transactional<BR/>... changeUserName(User user,String newUsername)<BR/>{<BR/> if (!userWithUsernameExists(newUsername))<BR/> {<BR/> user.setUsername(newUsername);<BR/> update(user);<BR/> }<BR/> else<BR/> {<BR/> // throw some error<BR/> }<BR/>}<BR/><BR/>.. Why do you call Anonymousnoreply@blogger.com