[Zope] Re: Zope Persistence (was: XML-RPC within ZOPE)

Michael Haubenwallner michael at d2m.at
Fri Dec 16 06:46:04 EST 2005


Jan-Ole Esleben wrote:

> Thanks; this is a problem we are well aware of. Our solution is to
> increase the amount of workers, obviously.
> 
> However, I'm increasingly getting a feeling that for a rather big
> range of unlikely situations that are nonetheless to be expected, Zope
> doesn't work _at all_. In a WebServices setting, situations like the
> one I described, with one server calling back to another server within
> a call from that latter server and both not knowing anything about the
> implementation of the other, it would most certainly be extremely hard
> to foresee the exact setup of such situations and impossible to
> exclude them for persistent objects that actually _do_ change state
> (unlike mine). The solution is to not have state in your objects, and
> thus lose instantly most of what Zope is.
> 
> However, as I see it, the problem is that what Zope actually _is_
> (i.e. mostly the ZODB) is an unhealthy way of coupling data and
> implementation (which is _exactly_ why my implementation didn't work
> immediately). This of course comes from its origins in TTW development
> where there wouldn't actually have been many user made products.
> 
> Please tell me if I'm wrong with my assumption above, and why. I'm not
> trying to be inflamatory, this just has me really worried.
> 
> Ole
> 

You could try XMLRPCMethod.
It creates its own worker thread and has a configurable timeout.

Michael

[1] http://www.zope.org/Members/EIONET/XMLRPC

-- 
http://zope.org/Members/d2m
http://planetzope.org



More information about the Zope mailing list