Igor, this clarified a lot. Many thanks for your very detailed reply.
Kaspar
On 26.03.2009, at 19:30, Igor Vaynberg wrote:
there are three patterns to transaction management
the default pattern is session-per-transaction. this is not convenient
because after your business logic closes the tr
i already said OSIV that comes with spring doesnt support
transaction-per-request, so what makes you think i am using it or any
other filter? :) wicket has plenty of hooks to do this.
-igor
On Thu, Mar 26, 2009 at 3:36 PM, James Carman
wrote:
> On Thu, Mar 26, 2009 at 6:32 PM, Igor Vaynberg
>
On Thu, Mar 26, 2009 at 6:32 PM, Igor Vaynberg wrote:
> not if you buffer the response like wicket does by default :)
Right, but you have to make sure your filters fire in the correct
order, then. If your OSIV wraps around WicketFilter, then buffering
won't fix the problem. The exception will h
not if you buffer the response like wicket does by default :)
-igor
On Thu, Mar 26, 2009 at 2:34 PM, Maarten Bosteels
wrote:
> Igor,
>
> IIUC, transaction-per-request will commit AFTER the response has been
> rendered, right ?
> That means that there's also risk for inconsistency: when the commi
On Thu, Mar 26, 2009 at 5:34 PM, Maarten Bosteels
wrote:
> Igor,
>
> IIUC, transaction-per-request will commit AFTER the response has been
> rendered, right ?
> That means that there's also risk for inconsistency: when the commit
> fails, user will think everything is fine, but changes are rolled
Igor,
IIUC, transaction-per-request will commit AFTER the response has been
rendered, right ?
That means that there's also risk for inconsistency: when the commit
fails, user will think everything is fine, but changes are rolled
back.
Or am I missing something ?
Maarten
On Thu, Mar 26, 2009 at 7
there are three patterns to transaction management
the default pattern is session-per-transaction. this is not convenient
because after your business logic closes the transaction you can no
longer use the session in the ui.
there are two ways to solve this: either use session-per-request -
which
On Thu, Mar 26, 2009 at 8:31 AM, Kaspar Fischer wrote:
> 1. Is it correct that there are two variants of the pattern?
>
> In one variant there is a single transaction (and a single session) that
> gets committed at the end of the request, as described in [1]. If I am not
> mistaken, James's wicket
I am learning about the OSIV pattern and have so far read the
introduction at hibernate.org [1], the Spring JavaDoc for
OpenSessionInViewFilter [2], the excellent MysticCoders tutorial [3]
that uses Spring's OpenSessionInViewFilter, and some more.
I have basic questions:
1. Is it correct t
