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 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_ 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 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, you have these problems all the time.. > > > > > > johan > > > > > > > > > On Jan 24, 2008 10:32 AM, Sam Hough <[EMAIL PROTECTED]> wrote: > > > > > >> > > >> 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 the user > > >> managed > > >> to load that page again I don't want them linking to an object that > > >> wasn't > > >> created. > > >> > > >> We are currently using pretty fine grained interactions with the > model > > so > > >> it > > >> would be quite easy to forget and modify the page too early when the > db > > >> transaction might be rolled back. > > >> > > >> Cheers > > >> > > >> Sam > > >> > > >> > > >> > > >> Johan Compagner wrote: > > >> > > > >> > 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 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 checking that I need to take more > care? > > eg > > >> If > > >> >> calling a method that may fail I shouldn't pass an argument that > is > > >> >> attached > > >> >> to the page that might be modified by that method before the > commit > > >> >> works? > > >> >> > > >> >> I take your point that quite often we would just show the user an > > >> error > > >> >> page > > >> >> but assuming we get the back button to work properly I think I > need > > to > > >> >> ensure the server side page is in a valid state. > > >> >> > > >> >> Thanks for the tip about Spring annotations, we were just using a > > >> single > > >> >> commit at the end of the request. > > >> >> > > >> >> Cheers > > >> >> > > >> >> Sam > > >> >> -- > > >> >> View this message in context: > > >> >> > > http://www.nabble.com/db-transaction-boundary-tp15042959p15060686.html > > >> >> Sent from the Wicket - User mailing list archive at Nabble.com. > > >> >> > > >> >> > > >> >> > > --------------------------------------------------------------------- > > >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> >> For additional commands, e-mail: [EMAIL PROTECTED] > > >> >> > > >> >> > > >> > > > >> > > --------------------------------------------------------------------- > > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> > For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > > >> > > > >> > > > >> > > >> -- > > >> View this message in context: > > >> > http://www.nabble.com/db-transaction-boundary-tp15042959p15061342.html > > >> Sent from the Wicket - User mailing list archive at Nabble.com. > > >> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> > > > > > > > > > > -- > > View this message in context: > > http://www.nabble.com/db-transaction-boundary-tp15042959p15061897.html > > Sent from the Wicket - User mailing list archive at Nabble.com. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
