Ames Andreas (MPA/DF) wrote at 2004-4-23 13:13 +0200:

... Dieter Maurer <dieter@handshake.de> writes:

...

You mean ZEO client instances not ZEO (server) instances, don't you?

Exactly, sorry for having been ambiguous.

...

Why do you think your ODBC objects should be consistent across ZEO clients? I do not think that it is necessary as all your requests your be independent which means all transactions inside a single request which implied that connections need not to be shared.

The reason why I think about this ZEO scenario is that I thought it was a goal for a ZEO deployment that all ZEO clients behave identical when they respond to the same request. That requires some sort of shared state, which is what ZODB is used for in ZEO, AFAIK.

You really must read my messages very carefully: Try to make requests self contained (Zope usually helps you with this), then you do not need shared state between requests and therefore, the state need not be shared across ZEO clients. ZEO does not use the ZODB to implement shared state. Instead, ZEO is used to allow multiple ZEO clients to access the same storage concurrently (a storage can only be accessed by a single process at a time -- you need an intermediate process (ZEO) when several processes need to access it concurrently).

Furthermore such shared state is only useful when the state persist across requests. So I guess my real question should have been:

Is it useful/sensible to keep state across request-boundaries within a database adapter in Zope

It may be for efficiency reasons (for resources that are expensive to set up).

(such state as ODBC-environment, ODBC-connections, ODBC-statements and ODBC-descriptors)?

If you don't know ODBC well enough: How do you do it in comparable remote access adapters (for example a CORBA client in Zope or something)?

I already suggested in the previous message that you look at a database adapter (why not "mxODBC") to see how they handle this issue... It is also essential to read my messages completely ;-) -- Dieter