Saga continues ([Zope-DB] DCOracle2: close connection doesn't)
dieter at handshake.de
Wed Oct 8 11:47:20 EDT 2003
Bo M. Maryniuck wrote at 2003-10-6 12:35 +0200:
> On Friday 03 October 2003 21:59, Dieter Maurer wrote:
> > Zope drops connections but not *during* long running queries.
> Ah, this... Finally I understood you at this point. Sure it does not drops
> during running queries, because this could be a huge crime! But this does
> means anything. If I tell Zope "keep it for later use" and he drops anyway,
> than I think it is plain wrong.
While you might have thought you had told Zope to keep it, in fact, you
did not. The "volatile" in "volatile attributes" is there for a purpose ;-)
> So folks here around call this very
> correctly: "Zope drops the connections".
Maybe, you used it in this flavour.
Someone else used "drops the connection" in the meaning of
"blocks a connection indefinitely" such that Zope no longer
uses up to "n" ("n" e.g. 4 or 7) concurrent worker threads
but just 1.
> > Zope drops old objects from its ZODB cache at transaction boundaries
> > only (and when you flush the ZODB cache).
> Well, this "old" by Zope current approach means by these definitions:
> 1. "I don't know exactly how old it is because I never met him before. So I go
> shoot it right now".
> ...or in this way:
> 2. "I met an object. It is a volatile attribute, so smells it already or not
> -- not my problem. Garbage collect depends from my random choice kill it or
> still leave it here. To be or not to be?".
Volatile attributes are a side effect of the ZODB cache. They live
as long as the object remains in the cache. They disappear when
the object is flushed from the cache.
As with any cache, there must be a replacement strategy (otherwise,
the cache would grow indefinitely). The ZODB cache maintains
cached objects in a (doubly linked) ring with an explicit head.
When an object is located via the cache (there are ways to access
an object without the cache noticing this), the object is moved
to the head. When the cache performs garbage collection,
it removes objects from the rings tail until the target size
> I don't care for this. I care to db.close() which DOES NOT WORK in any case
> because of volatile attributes. Connections should not fly in air in random
> way as they doing right now where close the current connection is like to
> whack a fly -- if you success, than OK... Flushing the Cache -- sounds like
> spray in air the fly poison "RAID" to kill all the connections, which is not
> in use.
The purpose is to cache objects between requests. That's a good idea!
Apparently, it works for lots of people (including myself).
Apparently, it does not work for you and you found a solution
(as you told me in private mail).
If you really want to use your application without the ZODB cache,
this is easy to achieve. Your application will just get slower...
> Instead, connections should be hardly registered and traced in details: who
> what where and how long doing something for what reason.
All frameworks have services for some tasks and lack them for others.
The ZODB framework provides (and documents!) volatile attributes
and implements them as documented.
It does not provide services to specify things like: this attribute
should live as long as the current user's session.
In fact, it would be entirely unnatural to have such a service at ZODB
level which knows nothing about the current user and its sessions.
You have tried to use volatile attributes for this and you failed --
rightfully! You have now a specialized solution for your specialized
> > Therefore, it does not drop this connection
> > (unless you flush the ZODB cache manually).
> Ironically, but flushing ZODB does not that help. Sometimes Zope thinks like
> my second definition. IOW, some of fly still alive because of small poison
> dose. ;-)
Maybe, that was your setup which added the poison...
Volatile attributes do disappear when the object (they are attached to)
is flushed from the ZODB cache.
More information about the Zope-DB