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

[Bo M. Maryniuck]

On Thursday 02 October 2003 11:42, Dario Lopez-Kästen wrote:
> What I cannot live with
> is Zope waiting for a response on a connection that was dropped for some
> unknown reason.

The reason is: connection object is stored into volatile attribute to be 
stored without pickling. When __setstate__() is called (and called all the 
time) you call that object, if there is no such connection, then 
self.connect(self._connection_string) called in Connection.py (AFAIK). This 
approach completely sucks when you need stable as a rock DB session, which 
will stay as long as you need and disappear exactly when you will need it. 
*Usually* volatile attributes lives longer than you do stuff in DB session, 
therefore you have illusion that you have stable DB session. But untill you 
need REALLY disappear the session, you need try to minimize the cache, or 
even restart the Zope to get threads be turned off. Well, I just get rid this 
approach and now I see much better results yet.

Now, I found the way where to store the connections and see light edge of that 
dark forest: just don't use volatile attributes, which living its own life as 
they want, since they can go away immediately, can go away after an hour, but 
can live week or more... In theory, if you do "_v_attr = None", then it 
should disappear, but in practice it does not. Why -- dunno, I have no such 
resources and enough cache to get it know.

The solution I found -- just use global variable at the module level, if you 
want, with locks. I still can't claim it is stable as a rock, because I just 
testing it for now, though seems it is to be really what I need and DB 
connection ain't dropped untill I drop it and disappears exactly when I want. 
But to get it, I wrote my own Oracle DA, based on DCOracle2. Also this causes 
that I need my own ZSQLMethod, SP and other stuff (acl_users, etc) to let 
them know which exactly connection to use from the Zope session and how to 
authorize users. I have it all together already and result is even better, 
because standard ZSQLMethod and SP has some problems with Oracle etc. and 
also (I said it before) I did adnother one XSQL and XML output instead of 
results object. There is already connection-per-user, which means one single 
Zope session corresponds to the one single session in Oracle. One user, one 
channel, one request. This what I need and what I already get (finally!).

P.S. There is another good trick with my SQL method: I just can limit number 
of rows at the Oracle side, then fetchall(). This seems to be works faster.

-- 
Regards, Bogdan M.Maryniuck

System programmer, Forbis UAB