Jan-Ole Esleben wrote at 2005-12-16 12:40 +0100:
... 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
Coupling data and behaviour (what you might call "implementation") is the main feature of object orientedness. I find this very productive (especially multiple inheritance). Apart from that: for all solutions you have to make tradeoffs based on your aims. The ZODB aimed at ease of integration and ease of implementing simple multi-threaded applications (such as Web application servers). To make the second easier, it removed a major fault class: locking faults in application code. With the ZODB, you need not to worry about setting locks to make the modification of persitent objects safe. Because of that, you will usually not have problems with deadlocks or data inconsistencies due to forgotten locking. However, this ease has a price: the quite costly ZODB cache maintained for each connection in a connection pool. To limit RAM consumption, the ZODB versions before 3.4 had a limit on the number of connections in the pool. With ZODB 3.4, the number of connections are no longer limited. Connections exceeding the pool size become temporary connections the cache of which is destroyed when the connection is closed. Thus, you can now have a rather small number of ZODB connections (to hold RAM consumption in check) and a rather large number of workers to reduce the risk of deadlocks caused by resource exhaustion. If you are ready to modify ZServer a bit, you could even create workers on demand (usually, they are preallocated). However, this will cost you much of your control over resource usage...
(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.
I do not think that it has anything to do with TTW development. It is just that Zope did not target arbitrary web services implementations but much simpler web applications such as blogs, CMS, portals, ... This applications usually do have a precise notion of interior and exterior of themselves -- no need to call back to itself via HTTP rather than caller back directly. If you are smart (and you do not want to replace Zope by a different system altogether), then you will implement your own WebServices dispatcher -- one that recognizes when the call it in fact internal and then does make an internal call. If such calls are frequent, then you will gain performance as well. -- Dieter