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;
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
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
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
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
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
