[Zope-DB] Problems with transaction management and many database adapters

M.-A. Lemburg mal at egenix.com
Wed Feb 4 16:37:36 EST 2004

Dieter Maurer wrote:
> Marco Bizzarri wrote at 2004-2-3 16:29 +0100:
>>The problem is in the paflow.js javascript file, which is in the 
>>standard_html_header. The browser, behind the scene, after getting the 
>>index_html, tries to get the paflow.js. However, since this is not 
>>present, it raises a resource not found error, and sends back to the 
>>browser an error page (which is not shown to the user, since this error 
>>is silently captured by the browser). The error produces a 
>>standard_error_message page, which, by default, includes the 
>>standard_html_header, which calls the menu_html which calls the SQL 
>>Method (oh gawd!). Here is either the feature or the strange behaviour: 
>>this is the second transaction which is not closed (no commit/rollback 
>>at the end). Is this a known behaviour?
> It is known:
>   Transactions modified during error handling are not properly
>   committed/aborted.
> There has been a long discussion between Toby and me on "zope-dev".
>   Toby convinced me that the abort should happen after
>   error handling (and not before, as does the usual Zope code).
> I fear, the problem is still present in all official Zope versions.

Is there some way to work around this caveat ?

Marc-Andre Lemburg

Professional Python Services directly from the Source  (#1, Feb 03 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
2004-01-23: Released mxODBC.Zope.DA 1.0.8        http://zope.egenix.com/

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

More information about the Zope-DB mailing list