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

[Dieter Maurer]

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