On Jun 28, 2007, at 9:58 AM, Jonathan LaCour wrote:
> > Michael Bayer wrote: > >> just to clarify, however this works, it should be *really easy* for >> individual controller methods to be marked as "transactional" or not. >> I have written decorators like these already, in the style of: >> >> class MyController(...): >> def index_page(self): >> ..... >> >> @transactional >> def post_message(self): >> ..... >> >> def display_message(self): >> ..... >> >> so id want that kind of thing to be readily available, i suppose it >> would communicate with the WSGI middleware on a per-request basis. > > The only issue I can see with this is that having the transaction > begin > in the controller method itself might be too late if you have other > things going on in middleware or elsewhere and something goes wrong > before you even get to the controller method -- say in object > dispatch, > the new TG controller's "lookup" method, or even some middleware that > stores sessions in a database for example. the way this idea works is that if some wrapping component knows it needs a transaction, it opens one. then the controller method participates in that transaction, regardless of whether or not its marked as @transactional. >> but another thing i like, is that of the response to the request >> being >> delivered *after* the transaction commits. i have raised this issue >> on the pylons list before but i dont think i impressed anyone. if you >> render your response template, then your transaction fails, you have >> the potential for that response template to still be delivered with >> the "success!" message. anyway, might be nice for the middleware to >> address this if possible. > > I am totally with you here, as this is the other side of the coin that > I brought up above. Open transactions shouldn't be committed until > the > latest possible point. yes. im talking specifcally about the way Pylons passes off from controller to view...right now you call render_response(), which typically renders the entire template in a buffer before the controller method has finished. id favor changing the behavior of render_response() to creating a "deferred" render object which Pylons explcitly places outside the scope of the controller call (however, probably still within the scope of enclosing middleware). > > I spent some dark days working on J2EE applications, and while there > isn't a whole lot that is worth emulating in J2EE, the transaction > handling is something that I actually liked. thats where im getting this from. theres subtleties to it that you cant emulate casually. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
