[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