I had the same problem while using the opensessioninview pattern. Since this pattern in struts uses an interceptor, in the OSiV interceptor I checked to see if validation had failed in an Action. If so, I "rolled back" the transaction to make sure it didn't persist the data. I eventually removed this "roll back" logic because I thought it was more of a hack than a solution. I also ran into some issues with the evict() method so didn't go that route. Eventually I moved to manual commit using JPA with Hibernate and managed the process myself. Hibernate's default setting is auto commit = true. I think you'll find controlling the process yourself is not that difficult and makes for cleaner code.
On Mon, Jul 20, 2009 at 2:07 PM, Greg Lindholm<greg.lindh...@gmail.com> wrote: >> Thank you very much!! >> >> During my research, I remember some one solved the issue by creating an >> Struts 2 intercepter. He placed the intercepter right after the >> validationIntercepter. The job of the intercepter was to check if >> getActionErrors or getFieldErrors collections was not empty than it closed >> and flushed the entityManager. But he didn't specified what intercepter >> method (before, inside or after the action was invoked) he implemented. >> >> Do you think this is a solution ? >> Any disadvangages ? >> What intercepter method do you think will be the correct one to implement? >> >> >> > You could probably make this work. You can take a look at the Workflow > Interceptor as an example of how to tell if there are errors. > > You would have to do your stuff before calling invocation.invoke(); cause > after is too late, the result will have already been rendered. > > Disadvantages are hard to determine, depends a lot on how you are managing > your Hibernate sessions. If you clear() /close()/rollback you are throwing > away all changes in the Hibernate session not just the one object you that > failed validation. To avoid these issues that is why I always work with a > copy of the db object. > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
