Comment 14 for bug 44032
Revision history for this message
| Stuart Bishop (stub) wrote Re: [Bug 44032] Re: Possible use of more than one connection ID on a single thread may be the cause of many OOPSes | #14 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
Steve Alexander wrote:
> I think the rollback is caused by the form processing machinery.
> GeneralForm, and the various EditForm and FormView variants all do an
> abort() if there is a WidgetError.
>
> This is dangerous. I think we implicitly start a new transaction after
> an abort(). What we should be doing is "dooming" the transaction, so
> that by the time we get to the end of publication, the publication knows
> it must not commit the transaction, but instead will always abort it,
> regardless.
>
> Sometime ago, I proposed a doom() method for the transaction manager API
> in Zope. We can do an equivalent thing either by extending the TM api
> or hooking into the publisher.
Is it obvious what the abort() in EditForm is attempting to do? If it is to
ensure that the transaction is never committed (by aborting the transactions
and deliberately not starting a fresh one), then the bug would be in the
psycopgda because it will automatically start a fresh transaction.
If this is what the abort() is supposed to achieve, I think that doom()
would be good as I can imagine other code that hooks into the transactional
system such as the email delivery subsystem will have the same behaviour.
doom() would ensure that commit() is a noop or raises an exception I assume?
--
Stuart Bishop <email address hidden> http://
Canonical Ltd. http://