I think you'd be happier if you went with @Transactional annotations
on your services. It works out much better, IMHO.
On Wed, Oct 14, 2009 at 12:23 PM, Iain Reddick
<iain.redd...@beatsystems.com> wrote:
> I'm considering it :)
>
> There are a lot of benefits to doing transactions at service call level
> ("truthful" user feedback for one, not having to deal with requests for
> resources hitting the transaction filter being another). Spring's AOP
> support actually makes doing this as simple and maintainable as it's ever
> likely to be (@Transactional annotations, or marking a whole class as
> transactional), so if we decide it's necessary it is reasonably trivial to
> implement.
>
> The main pro for per-request transactions is the complete seperation of
> transaction concerns.
>
> In the meantime I have a Filter-based solution, or I can hook into the
> wicket request cycle.
>
> iainr
>
> For now,
> James Carman wrote:
>>
>> 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
>> <iain.redd...@beatsystems.com> 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: 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
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
