[Zope-DB] Re: Zope-DCOracle2 vs Tomcat-JDBC performance

[Umberto Nicoletti]

Dieter Maurer wrote:
> Umberto Nicoletti wrote at 2003-5-26 08:59 +0200:
>  > ...
>  > So I am lead to conclude that maybe something is 'wrong' with the thread 
>  > implementation in Zope/Python.
>  > I read something about it and, if I recall correctly, it stated that if 
>  > a thread was not 'well behaved' in the sense that prior to call a 
>  > potentially locking external subroutine (as it is the case with Oracle 
>  > apis, or with file I/O) it didn't release locks, it could hang the 
>  > interpreter thus slowing down the whole thing including, in the case of 
>  > Zope, the serving of 'static' pages.
> 
> That is right. But you will see it only for concurrent requests.
> 
> An indication for this problem is that during a long database
> operation, Zope is not responsive.

And in fact this is what you can experience while running the test and 
just trying to display the Zope welcome page. The whole app is frozen 
eating 100% cpu.

> 
> As far as I know, the DCOracle adapter (I used only DCOracle
> and not DCOracle2) does not have this problem. At least,
> I did not observe it.
> 

But whe use Oracle 8.1.7, so I guess we must stick with DCOracle2.

>  > Do you think that stackless python could help here (please bear with me, 
>  > this is a *wild* guess)?
> 
> No, it will not help with this.
> 
> The threading restriction is motivated by Python "Reference Counting"
> scheme for garbage collection. To make it efficient, a global
> lock is necessary. Any Python implementation with reference counting
> is likely to have the Global Interpreter Lock (I found in comp.lang.python,
> that there was a Python version without the GIL but it was so slow that
> it was soon be dropped again).
> 
> 
> Dieter

So are we at a point where there is not much to do? are we forced to 
ditch Zope for such database intensive applications?

Thanks,
umberto