That's the problem with transaction-per-request. Why not put your transaction around your service/domain methods rather than around the entire request cycle?
On Wed, Oct 14, 2009 at 5:19 AM, Iain Reddick <[email protected]> wrote: > For anyone in this situation (having to use a transaction filter), here is a > solution that uses a response wrapper to delay the redirect until after the > transaction has completed: > > private class DelayedRedirectWrapper extends HttpServletResponseWrapper { > > private String redirectLocation; > public DelayedRedirectWrapper(HttpServletResponse response) { > super(response); > } > @Override > public void sendRedirect(String location) throws IOException { > redirectLocation = location; > } > public void doCachedRedirect() throws IOException { > if ( redirectLocation != null ) { > super.sendRedirect( redirectLocation ); > } > } > } > > This is then used in the filter's doFilter method like this: > > ... > DelayedRedirectWrapper responseWrapper = new DelayedRedirectWrapper( > response ); > beginTransaction(); > filterChain.doFilter( request, wrappedResponse ); > doCommit(); > endTransaction(); > responseWrapper.doCachedRedirect(); > ... > > You could easily put the redirect-delaying code in it's own filter, for > re-usabilty. > > > iainr > > Iain Reddick wrote: >> >> Hi, >> >> I'm working on a Wicket / Hibernate / Spring app, with a configuration >> that uses spring's OSIV filter and my own transaction filter (basically a >> transaction per-request pattern). >> >> I've run into a problem involving the order of transaction commits and >> redirect reponses (triggered by setResponsePage()). >> >> The problem state is shown below: >> >> 1. User submits a form to create a new entity >> 2. Submit handler calls service to save new entity >> 3. Submit handler calls setResponsePage for page showing overview of new >> entity >> 4. Wicket request cycle completes (I'm assuming this is where wicket does >> the response.redirect()) >> 5. Redirect is sent to browser >> 6. Browser requests new page, which fails as backing entity hasn't been >> persisted yet >> 7. Transaction is commited, and new entity is persisted >> >> This is obviously a race condition between 6 and 7 (i.e. if 6 and 7 are >> reversed, everything is OK). >> >> Now, I'm aware that this isn't a wicket-specific issue, but the way wicket >> works as a framework means that this situation is much more likely than in a >> model 2 style framework. >> >> Is transaction per-request using filters a reasonable configuration to use >> with wicket and, if so, how can I ensure that any redirects occur after my >> transaction has been committed? >> >> (My guess is to use onBeginRequest and onEndRequest, but that assumes that >> onEndRequest happens before redirection) >> >> >> iainr >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
