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 any updates/inserts then commit _before_ any modifications to the page" then all will be well. Also need some extra care that arguments to methods within the transaction are not modified by the implementor as they don't know if they are attached to the page. Will take my tired old mind to get a grip on the implications of that rule. Cheers Sam Johan Compagner 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] >> >> > > -- View this message in context: http://www.nabble.com/db-transaction-boundary-tp15042959p15068935.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]
