On Thu, 2011-08-04 at 13:03 -0500, Matt Feifarek wrote: > On Thu, Aug 4, 2011 at 12:06 PM, Chris McDonough <chr...@plope.com> > wrote: > > I kinda feel like there is still a larger question here, > though... > > using transaction manager, code that is executed in a view > callable > > doesn't *really* finish till after the users' function is > over... so > > there's no chance of cleaning up if the transaction fails. > > > Actually, there is: > > http://www.zodb.org/zodbbook/transactions.html#after-commit-hooks > > > Neat, that's helpful, thanks. In critical cases, one can use this... > but it's not the usual Pyramid pattern, so the larger philosophical > question still stands, IMO: when using transactions, how all-in does > one have to go?
I guess in a sense the answer is "none" and "a lot" at the same time. The transaction machinery provides a hook to do something based on the commit status. If the transaction has aborted, do X; if it has committed, do Y. There's probably second-order details that would need to be addressed in any particular integration that uses the after commit hook but without seeing code it's hard to make any sort of general statement about it. You could also just choose to ignore the transaction manager and handle all commits yourself. In my experience, this is a poor idea, but people seem to make it work. > We actually can and do make file io transactional: > http://docs.repoze.org/filesafe/ > > > Also cool, but it wouldn't work for deletes, renames, etc. It does handle deletes, actually. The rendered docs are apparently out of date, see deleteFile in: https://github.com/repoze/repoze.filesafe/blob/master/repoze/filesafe/__init__.py . And renames are just deletes and creates. If you're using ZODB, you have Blob objects, which, although they're not documented very well, make file IO 100% transactional. See http://simon.pamies.de/archives/297 for some example code. > Is there an actual problem here that can't be solved by either > making > sessions transactional or by after-commit? > > > I am not having an "actual problem"... I had one, but it was pilot > error, and it's gone. It's more like a theoretical problem. Does that > annoy you ;-)? No so far. ;-) But it probably will if it goes on much longer without any code being shown. A codeless conversation seems more suited to be had over a beer or in a consulting engagement than to be had over the maillist, I think. > As I grok pyramid, I'm seeing the theoretical chance to write unsafe > code when using transactions; I can internalize the possibility as I > code that a "partially" successful login event needs to be treated > very carefully. I suppose it's a side effect of repoze.tm being in the > pipeline and "magically" saving my database changes when I don't have > to. Of course I don't have to use this feature, I know... Maybe. I really dont know. I've internalized the transaction pattern so much and I've written so much code that relies on synchronization of multiple storages via a single commit point that I tend to think of code that uses multiple storages and which doesn't use a transaction manager as broken by design. It's possible that you might be able to make a particular setup work deterministically without one though (like one database, no filesystem stuff, and a session storage) if you're careful enough. > This discussion is teasing out some things, I think: > 1. Sessions should be transactional if transaction manager is on the > stack. (as you've said like 3 times now) > 2. perhaps we need a cookbook entry coupled with some fancy > view-callable handler code that supports after-commit. > > > (Forgive me if these things are all boring done-deal items in the Zope > land, I'm not from that world.) Those things above sound reasonable. (FTR, that's not me volunteering to do them right now, just an agreement they sound reasonable and deserve an entry in some TODO). - C -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
