Well, for a different example, how about setting up a Hibernate Session and then closing it on the way out? Then Hibernate can manage your transactions.
> -----Original Message----- > From: Hani Suleiman [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 09, 2003 10:35 AM > To: [EMAIL PROTECTED]; Patrick Lightbody > Cc: os-ww > Subject: Re: [OS-webwork] XWork Interceptors > > > I have to say, I really do think that adding tx on this level > is a bad idea. For one thing, webwork is NOT a tx system, > whatever it talks to should provide whatever tx support you > require. Reinventing the wheel by handling the tx on this > level seems....a waste of effort (vendors have already spent > years getting their tx impls to work very nicely). > > To my mind (I'll admit I didnt read all the previous emails > about interceptors in great detail, so I might be repeating > old/known/wrong stuff), interceptors are pretty much like > filters. An interceptor would choose what to intercept, then > have access to context and whatnot to adds its own stuff. It > can choose to then keep passing the request, or bail out. > Similarly, an interceptor can be applied post-action. > > Quoting Patrick Lightbody <[EMAIL PROTECTED]>: > > > So anyway, I'm just going to disregard the "Documentation" > thread and > > start a thread that is actually useful :) > > > > (Though, Ken, we're still hoping your willing to do some Doc work!) > > > > So besides Action Chaining, Rickard made a good point that > > interceptors is very important as well. I'd like to talk about the > > actual implementation now -- using the transaction scenario as an > > example. > > > > How will the interceptor know when to rollback or commit? > Of course on > > an Exception it should, but what about on ERROR or INPUT? > What if the > > action, to signify it's is complete, used COMPLETE instead > of SUCCESS? > > Do you see my point? How can we make interceptors work for > all cases? > > I'm guessing some sort of configuration is needed for each > interceptor > > on each action, so we could do something like: > > > > <interceptor class="..."> > > <param name="commit.values">success, complete</param> > > </interceptor> > > > > And then the interceptot could know to rollback if the return value > > isn't one of those two. > > > > Rickard, is this what you had in mind? > > > > Also, Interceptors would fit in to the GenericDispatcher > area. I think > > that they would replace ActionFactoryProxies entirely, > correct? Also, > > maybe Rickard you can provide some sample psuedo code for an > > Interceptor as well as how it would go about being invoked in > > GenericDispatcher? > > > > -Pat > > > > > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld = > Something 2 See! > > http://www.vasoftware.com > > _______________________________________________ > > Opensymphony-webwork mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > > > > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something > 2 See! http://www.vasoftware.com > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
