How are you marking your transaction boundaries? The
OpenSessionInViewFilter doesn't start a transaction. It merely opens a
session. So, the entire request doesn't go on within one transaction.
On 1/24/08, Johan Compagner <[EMAIL PROTECTED]> wrote:
>
> if the rendering of the page (the response
Johan,
Definitely report the error but just ensure server side state is not updated
(so that if that part of page is resent after the error it doesn't show the
user rubbish). So I think I did have the transaction boundry in the wrong
place (servlet filter).
Presumably if I stick to the rule "do
if the rendering of the page (the response phase) always uses a committed
transaction
then that wouldn't happen
But if a commit fails, shouldn't you report that to the user anyway??
johan
On Jan 24, 2008 10:59 AM, Sam Hough <[EMAIL PROTECTED]> wrote:
>
> Johan,
>
> But isn't wicket _very_ diff
Johan,
But isn't wicket _very_ different in that it keeps a representation of the
page on the server? So in frameworks other than Wicket, Echo and Tapestry if
the request cycle fails the page state can't get contaminated?
Cheers
Sam
Johan Compagner wrote:
>
> so you want to have the commit c
so you want to have the commit cylce around the request not the response
(so in onBeforeRender() of a page the commit (or rollback) should be done so
that all the data that is used in the response is valid)
But i guess with a filter (session in view and the sort) around what ever
framework you use
Hello Johan,
The simplest case I can think of is the one where the user clicks to create
a new record and I want to put a link in the page to that new record. As I
understand it I need to be careful not to add the link to the page until
after the commit was successful. If there was an error and t
So you are worried about double submit, when using backbutton, of the
same page that has invalid data?
But if that happens then the second time has the same error as the first time.
On 1/24/08, Sam Hough <[EMAIL PROTECTED]> wrote:
>
> Igor,
>
> Am I at least correct that we shouldn't only commit a
Igor,
Am I at least correct that we shouldn't only commit at the end of request
processing as you might in struts? (because I need to know if the commit was
good before updating the page)
I'm not really saying that you can't safely handle transactions and page
state in Wicket just sanity checkin
On Jan 23, 2008 5:03 PM, Sam Hough <[EMAIL PROTECTED]> wrote:
>
> Thanks Igor,
>
> >> Where is the typical place to put the transaction boundry in a wicket
> >> app?
> >wherever youd like, wicket apps are no different then other webapps in
> >this regard
> Isn't Wicket a bit different in that it ha
Thanks Igor,
>> Where is the typical place to put the transaction boundry in a wicket
>> app?
>wherever youd like, wicket apps are no different then other webapps in
>this regard
Isn't Wicket a bit different in that it has more server state? So I need to
take more care at least in comparison to s
all in one shot ) or will cause a heavy db load ( every component
retrieving data by issuing queries )
-igor
> btw Is there a wicket core dev beer fund or favourite charity? I'm asking a
> lot of questions but havn't got the time or energy to help out.
>
> Cheers
>
> Sam
asking a
lot of questions but havn't got the time or energy to help out.
Cheers
Sam
--
View this message in context:
http://www.nabble.com/db-transaction-boundry-tp15042959p15042959.html
Sent from the Wicket - User mailing list a
12 matches
Mail list logo
