Carol,

As a quick fix, we have created a stand alone program that does the database access.

So from the python external method (zope) that retrieves data, instead of making the connections to the DB directly it now calls os.popen(“python getdata.py”).

This forces the launch of a separate python interpreter for the duration of the query.

Unfortunately, we will suffer the overhead of doing this for each DB call, but that is far better than denying service to all other sessions.

We are already in the process of moving to MySQL for our databases, and the MySQL adapter does not appear to exhibit this behavior.

Jon Emmons

---

From: Carol Ludwig [mailto:csl@med.unc.edu]
Sent: Wednesday, June 04, 2008 10:58 AM
To: Jon Emmons
Cc: 'Dieter Maurer'; zope@zope.org
Subject: Re: RE: [Zope] Multithreading sessions

We are using Plone and Zope against a legacy Ingres database, and I found a similar problem
using the adapter provided.  I found that the C library modules (open source) actually contained
calls to make the adapter work as we wanted, much like our other web interfaces which maintain
the db and user permissions info as a "connection", but close the actual query after each.  I had
to modify the Python Zope product to set "autocommit" and call the desired close in order to get
the behaviour we were looking for -- keeping the connection, but releasing each session so that
 the DB backend does not register an active session between actual queries.

That's open source.  Code terminology for "re-write it".

----- Original Message -----
From: Jon Emmons <jon.emmons@earthwavetech.com>
Date: Wednesday, June 4, 2008 8:50
Subject: RE: [Zope] Multithreading sessions
To: 'Dieter Maurer' <dieter@handshake.de>
Cc: zope@zope.org

> Dieter,
>
> Thanks for this input.  Your comments here turned out to be
> dead on.  The
> problem is the GIL.
>
> We are currently running Sybase databases using the python
> Sybase-0.37
> module for data access.
>
> This module will set the GIL.  So if the query takes any
> time at all, every
> other session will freeze.  It does release it when the
> connection is
> closed, but if the query takes awhile it effectively denies
> service to every
> other session.
>
> I am just learning about this, but my initial inquiries suggest
> that the
> only way to achieve true concurrency using a language like
> python is to
> launch multiple interpreters.
>
> I don't yet have the solution to my problem, but at least now I
> know what
> the problem is, and that is half the battle.
>
> Thanks again, and thanks to everyone's input, it has helped immensely.
>
> Jon Emmons
>
> -----Original Message-----
> From: Dieter Maurer [mailto:dieter@handshake.de]
> Sent: Wednesday, May 28, 2008 2:27 PM
> To: Jon Emmons
> Cc: zope@zope.org
> Subject: Re: [Zope] Multithreading sessions
>
> Jon Emmons wrote at 2008-5-23 08:58 -0400:
> > ...
> >I am running zope 2.9.4 and have observed that it will not
> simultaneously>serve pages to my users.
>
> Usually, it does.
>
> I have seen database adapter packages (an old "psycopg" version,
> to be
> precise) that forgot to release the GIL for some operations.
> Then Zope freezes while these operations are executed.
>
>
> A surprising report of a similar kind was: while Zope's embedded
> profiler is in use, Zope effectively runs in single thread mode (such
> that other threads do not distort the timing results).
> Probably not your problem ... but who knows.
>
>
> Further potential reasons (for almost surely not responsible for your
> current problem:
>
>   Expensive operations implemented in "C" (such as
> operations on huge
>   strings)
>
>   Creating excessive amounts of objects (causing lots
>   of generation 2 garbage collections which hold the GIL)
>
>
>
> --
> Dieter
>
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://mail.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists -
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope-dev )
>