my favorite: declare @Transactional on the business beans itself (for
example Customer.findOrders()) and let salve inject the dependencies
and the transaction management logic.
http://code.google.com/p/salve
:-)
Am 14.10.2009 um 20:10 schrieb James Carman:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
