You can register a callback that is called after the transaction ends, so that the logging can be done there. See this page, near the end of the linked section:
http://zodb.readthedocs.org/en/latest/transactions.html#repoze-tm2-transaction-aware-middleware-for-wsgi-applications Carlos de la Guardia On Mon, Aug 1, 2011 at 11:06 AM, Matt Feifarek <matt.feifa...@gmail.com> wrote: > I am using tm2 in my Pyramid application, and both ZODB and pyramid_mailer > are hooking into that. However, other events related to the request > lifecycle are not aware of transactions and are thusly causing suprising > behavior that might be worth discussion. > For example, I create a new object from a form post, it all looks good, an > object is saved into my traversal container with an id of "54". I store this > object, and generate an email alert that says basically "new object created > with id 54". Also, this information is logged with python stdlib logging, > and a session flash message is made too. So 4 events happen: > 1. Object 54 is created and saved in the ZODB > 2. Email notification is generated and sent. > 3. python standard logging says "new object 54" > 4. Pyramid session flash message is added > Oops, I had misconfigured SMTP settings and the email didn't work, which > rolled back the transaction, as it should have, I guess. I actually thought > that the transaction only affected whether the email would go out, not > whether the email itself WAS part of the transaction... this is kinda weird, > so point one for discussion. > But now, events #1 and #2 are rolled back, but not #3, #4. So my session > object contains "Object 54 success" and so does my stdlog. > I fix the STMP problem, click reload, and I get 4 events again, this time > with a new id of 67 (since as Pyramid is concerned, it's a whole new > transaction). Now my data is saved, the email goes out, and I have two sets > of messages in logs and in session. So point two for discussion: what about > other events being tied to transaction... can we do that? The transaction > failure happens outside of my view code, so I don't know how I could do an > "if transaction.success(): do something". > So two points: why does (or should) pyramid_mailer hold-up database > transactions? And two: how to know whether transactions worked so as to > react appropriately. And/or, can we have session.commit() too? Obviously > tying std.logging into tm2 is a non-starter. > I'm also afraid how this might work with transaction retries... it's rare, I > know, but if it happened, would I get up to 3 sets of messages in my log and > session? > > -- > 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. > -- 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.
