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 struts like webapp with very little if any session state?
>> If I put it right at the front (servlet filter) then my pure UI >> components >> might get bad state as they won't get rolled back with the database >> state. >huh? Probably me being thick but what about: User clicks link to create new row in the database and I create a new link on the page to the new object. I need to be careful that the page state is not altered until _after_ the db has confirmed the commit? >> If I put it between my UI components and facade to middle tier then my >> components can't take advantage of lazy loading... >why not? i use spring's @Transactional and it works just fine. you >need to configure openentitymanagerinviewfilter or >opensessioninviewfilter depending on what persistance framework you >use. I'll have to do some homework on that! After all those years of struts like frameworks and client server it is tough for an old brain to learn good habits in this very different model :) The serialisation between client and server is a PITA and performance hole but is a safety barrier I've got very used to. So in old school the UI (HTML/JS) always gets a complete success or failure response while in Wicket I can accidently update the UI before knowing if this request will end in success or failure. Cheers Sam -- View this message in context: http://www.nabble.com/db-transaction-boundary-tp15042959p15056622.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]
