Saga continues ([Zope-DB] DCOracle2: close connection doesn't)

Dieter Maurer dieter at handshake.de
Mon Sep 29 13:56:51 EDT 2003


Bo M. Maryniuck wrote at 2003-9-29 10:29 +0200:
 > ...
 > OK, I did very-very-very simple test-product, which certainly only do on 
 > manage_afterAdd():
 > 
 > 	self._v_test_connection = DCOracle2.connect('asdf at qwer/zxcv')
 > 
 > And the method teardown() thich should close the connection. It does:
 > 
 > 	self._v_test_connection.close()
 > 	self._v_test_connection = None
 > 
 > 	del self._v_test_connection # This is really optional
 > 
 > So I had turned off any connection, have a pure plain Zope instance without 
 > any connection, than had runned SQL to select active Oracle users from 
 > p$session view and got no one in result. OK, let's go test it. 
 > 
 > Now I had added my test to ZODB and run p$session SQL again. Now I see one 
 > active session, exactly I did it. Now, I call teardown() method which means 
 > "Close Oracle session and disappear forewer". And after that I had deleted 
 > the test object at all. After that, SQL still shows me active connection. 
 > Huh?! Why???
 > 
 > So below is the interesting questions, which I really would like to get it 
 > know:
 > 1. Why my understanding is buggy, when I set my volatile to None and Zope 
 > still keeps the connection? Should Zope garbagecollect it instead?

You are working with a DCOracle2 connection directly.
When your "teardown" method is called (are you sure, it is?),
then Zope has no longer anything to do with it.

Thus, it is not Zope (in this case) that keeps your session alive.

 > 2. Why I think wrong, if I had DELETED this UNIQUE volatile and, in theory, 
 > Zope has no one else anymore but Oracle session still opened?

Zope is not to blame -- explanation above...

 > 3. Why I did Control_Panel.Database.manage_minimize() and Oracle session 
 > finally dissapeared?

I do not know the precise answer...

Some possibilities:

  *  A different ZODB connection held an Oracle connection.
     Minimizing flushed objects from the ZODB cache and closes
     connections.

  *  There is some "timeout" mechanisms (outside of Zope)
     that keeps the session alive for some time.
     
     The apparent relation with your minimizing may be accidental.

  *  For some reason, your "teardown/close" was not effective.

     Minimizing flushed the object from the cache and closed
     the connection.

 > 4. How else to say to my volatile: "Die immediately and release Oracle 
 > session!" in Python code, except call close(), delete it and set it to None?

You can right a non-volatile attribute in your DA.
This will flush all volatile attributes in all connections in
all ZEO clients (as the object is invalidated).
Not sure, you really want this...

Otherwise, you can only affect a volatile attribute in your own
ZODB connection. The copies in other connection caches are
unreachable (by normal means).

 > ...
 > Does 2.6 and 2.7 has some changes with volatile 
 > attributes since v. 2.5?..

No. But the ZODB cache has seen changes and is not more predictable
with respect to cache parameter observance.


Dieter



More information about the Zope-DB mailing list