>imho, your transactions should only be concerned with what happens in event >handlers (onclick/onsubmit) and not through the enitire request cycle because >anything outside the handlers should be read-only access and thus not require a >transaction.
That would indeed be desirable, however as of the latest hibernate you are required to have atransaction at all times. Even for read only operations. failing to do results in lazyinit exceptions from hibernate. Maurice 2005/12/17, Igor Vaynberg <[EMAIL PROTECTED]>: > yes. considering what you are trying to do that will work. > > still not sure why you are trying to do it this way, seems silly to me to > tie transaction handling with UI code. imho, your transactions should only > be concerned with what happens in event handlers (onclick/onsubmit) and not > through the enitire request cycle because anything outside the handlers > should be read-only access and thus not require a transaction. so i think > you are setting the boundaries a bit wide. but as i said, this is imho. > > anyway i created an example of what you want a while back - pre requestcycle > refactoring - so if you want to take a look you can find it here > > http://www.mail-archive.com/[email protected]/msg07587.html > > my approach was a bit inversed opposed to yours. i used the application to > handle sessions and used requestcycle to signal certain events to the > application. that way all transaction mgmt lives in the application. > > > -Igor > > > On 12/17/05, John Patterson <[EMAIL PROTECTED]> wrote: > > On Saturday 17 Dec 2005 15:19, Igor Vaynberg wrote: > > > you might not be able to do it using the try/catch/finally semantic, but > > > there are plenty of hooks in there to do it without. the > > > iexceptionresponsestrategy is indirectly part of the cycle as well. > > > > So the answer is no, you cannot have transaction handling code in one > class? > > > > This seems like it should be really simple to do so I am not sure I doing > it > > the way you suggest. > > > > Is this your suggested approach: > > > > 1 - Override > WebApplication.getDefaultRequestCycleFactory() to return > new > > instances of my own custom RequestCycle. > > > > 2 - Subclass WebRequestCycle to override onEndRequest() where I can > > commit/rollback the transaction. > > > > 3 - Override > WebApplication.getDefaultRequestCycleProcessor to create > and > > cache a single instance of CompoundRequestCycleProcessor with my own > custom > > IExceptionResponseStrategy. > > > > 4 - Subclass DefaultExceptionResponseProcessor to catch > exceptions and signal > > my custom WebRequestCycle that the transaction should be rolled back in > > onEndRequest(). > > > > Thanks, > > > > John > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > > for problems? Stop! Download the new AJAX search engine that makes > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > > _______________________________________________ > > Wicket-user mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
