> I don't understand the problem. How is using XML-RPC incompatible > with persistence? What are you trying to exclude?
I'm sorry, but I don't understand _that_ question. What am I trying to _exclude_? XML-RPC and (the concept of) persistence aren't incompatible. XML-RPC (on a ZOPE server) and ZOPE persistence are, to the extent described by others in this thread, not by me. I just described a couple more cases (and specifically one case) where it is bad that things are this way (and cannot be solved by better design). My point is: this doesn't happen _within_ single "programs", but everywhere there is even the slightest bit of communication there is a chance of it happening. Ole > > - C > > > On Dec 16, 2005, at 6:40 AM, 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 > > > > > > 2005/12/15, Dieter Maurer <[EMAIL PROTECTED]>: > >> Jan-Ole Esleben wrote at 2005-12-11 19:10 +0100: > >>> Is it at all impossible to use XML-RPC _within_ a ZOPE architecture? > >> > >> In principle yes. > >> > >> Be careful however: it is easy to introduce deadlocks! > >> > >> When during request processing you call back into the same > >> Zope via XML-RPC, the calling out request will not complete > >> until the XML-RPC returns a result (this always holds for > >> calls, XML-RPC or other, to an external or internal server). > >> > >> Zope has a limited amount of workers (the default is 4) able > >> to execute requests. If there are no free workers, requests > >> have to wait for one. > >> > >> Now imagine that as many requests arrive as there are workers > >> and each of them wants to perform an XML-RPC against the > >> same Zope. Then you have a deadlock: none of the XML-RPC requests > >> will finish, because there are no free workers. An no worker > >> will ever become free again, because each of them waits for > >> its XML-RPC to finish. > >> > >> Therefore, you should directly call internal resources (rather > >> than use XML-RPC). > >> > >> > >> -- > >> 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 ) > > > > _______________________________________________ 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 )