A fourth option that we came up with this morning is to make the data access
procedure a stand alone program.

We spawn a process at the OS level to query the data and pipe the results
back into the zope external method.  This launches a new python interpreter
and completely sidesteps thread locking issues.

Is this a graceful solution?  No.

Was it very quick to implement and required minimal changes to our code
base?  Yes.

Initial testing has shown that we no longer have sessions freezing up if
another session runs a long query.

Thanks again,

Jon Emmons

-----Original Message-----
From: Dieter Maurer [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 04, 2008 2:09 PM
To: Jon Emmons
Subject: RE: [Zope] Multithreading sessions

Jon Emmons wrote at 2008-6-4 08:50 -0400:
> ...
>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.

This is true when you mean by "true concurrency"
"can keep a multi-CPU systems busy".
One a single CPU system, you get almost the concurrency which is possible
(modulo bugs such as holding the GIL during non Python related possible
expensive operations).

>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.

One option is to fix the Sybase access module, another one to use
SQLRelay, a third one to access the Sybase database via ODBC.


Zope maillist  -
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to