We are using Plone and Zope against a legacy Ingres database, and I found a similar problem<br>
using the adapter provided. I found that the C library modules (open source) actually contained<br>
calls to make the adapter work as we wanted, much like our other web interfaces which maintain<br>
the db and user permissions info as a "connection", but close the actual query after each. I had<br>
to modify the Python Zope product to set "autocommit" and call the desired close in order to get <br>
the behaviour we were looking for -- keeping the connection, but releasing each session so that<br>
the DB backend does not register an active session between actual queries.<br>
<br>
That's open source. Code terminology for "re-write it".<br><br>----- Original Message -----<br>From: Jon Emmons <jon.emmons@earthwavetech.com><br>Date: Wednesday, June 4, 2008 8:50<br>Subject: RE: [Zope] Multithreading sessions<br>To: 'Dieter Maurer' <dieter@handshake.de><br>Cc: zope@zope.org<br><br>> Dieter,<br>> <br>> Thanks for this input. Your comments here turned out to be <br>> dead on. The<br>> problem is the GIL.<br>> <br>> We are currently running Sybase databases using the python <br>> Sybase-0.37<br>> module for data access.<br>> <br>> This module will set the GIL. So if the query takes any <br>> time at all, every<br>> other session will freeze. It does release it when the <br>> connection is<br>> closed, but if the query takes awhile it effectively denies <br>> service to every<br>> other session.<br>> <br>> I am just learning about this, but my initial inquiries suggest <br>> that the<br>> only way to achieve true concurrency using a language like <br>> python is to<br>> launch multiple interpreters.<br>> <br>> I don't yet have the solution to my problem, but at least now I <br>> know what<br>> the problem is, and that is half the battle.<br>> <br>> Thanks again, and thanks to everyone's input, it has helped immensely.<br>> <br>> Jon Emmons<br>> <br>> -----Original Message-----<br>> From: Dieter Maurer [mailto:dieter@handshake.de] <br>> Sent: Wednesday, May 28, 2008 2:27 PM<br>> To: Jon Emmons<br>> Cc: zope@zope.org<br>> Subject: Re: [Zope] Multithreading sessions<br>> <br>> Jon Emmons wrote at 2008-5-23 08:58 -0400:<br>> > ...<br>> >I am running zope 2.9.4 and have observed that it will not <br>> simultaneously>serve pages to my users.<br>> <br>> Usually, it does.<br>> <br>> I have seen database adapter packages (an old "psycopg" version, <br>> to be<br>> precise) that forgot to release the GIL for some operations.<br>> Then Zope freezes while these operations are executed.<br>> <br>> <br>> A surprising report of a similar kind was: while Zope's embedded<br>> profiler is in use, Zope effectively runs in single thread mode (such<br>> that other threads do not distort the timing results).<br>> Probably not your problem ... but who knows.<br>> <br>> <br>> Further potential reasons (for almost surely not responsible for your<br>> current problem:<br>> <br>> Expensive operations implemented in "C" (such as <br>> operations on huge<br>> strings)<br>> <br>> Creating excessive amounts of objects (causing lots<br>> of generation 2 garbage collections which hold the GIL)<br>> <br>> <br>> <br>> -- <br>> Dieter<br>> <br>> _______________________________________________<br>> Zope maillist - Zope@zope.org<br>> http://mail.zope.org/mailman/listinfo/zope<br>> ** No cross posts or HTML encoding! **<br>> (Related lists - <br>> http://mail.zope.org/mailman/listinfo/zope-announce<br>> http://mail.zope.org/mailman/listinfo/zope-dev )<br>>