[Zope-DB] Orace Saga again (Re: Saga continues)

[Bo M. Maryniuck]

This might be big mail, since I include most important. ;-)

On Thursday 23 October 2003 20:05, Chris Withers wrote:
> Why do you have so many threads?
It does not matter. I may have two, may have five, may have ten. Just making 
more threads seems make Zope a bit faster to answer.

> >>Well, it could catch the exception oracle throws and re-connect, surely?
> That's what I want to implement ;-)

Well, you can do the Thread then if timedout kill it.

> I'm currently looking at how the other DA's do this, the only idea that's
> popped into my head so far is a module-level variable storing the
> connection pool.

You're on a right way: that's what I'm currently doing. ;-)

But having stuff outside Zope is a pain a bit. To get all that gotchas you 
need do a lot. What is the first suggestion, is to commit nothing and 
rollback nothing untill Zope ask you. To get when Zope ask you do this, you 
should make a callback class by subclassing Shared/DC/ZRDB/TM.py I think and 
your callback should react on _abort()/_finish() stuff...

Well, by approach is to get single separated Oracle session to a single Zope 
user. But it differs...

> ZOracleDA threads can then retrieve a connection from this pool is a
> section of code protected by a python Lock and put it back when they're
> done.

Sort of. The only thing that your base target could be 
Shared/DC/ZRDB/Connection.py to let other adapters subclass it and have... 
erm... trouble, since they use _v_ attributes. Hm... Good question how to 
rework all this mess. First, what I found to suggest, _v_database_connection 
might be a _pointer_ to a real connection somewhere in the module-level 
attribute. In my case this attribute is a simple dict with the following 
format:

	zope_session_id + session_token = [connection, is_locked, timestamp]

It means, that you find your connection by session (id + token) and then you 
get actually a connection with db(), cursor() etc methods, "is_locked" is a 
flag which shows is connection in an SQL / Stored Proc use or not and finally 
timestamp which refreshes all the time on each __call__() anywhere since I 
had registered ZPublisher hook before traverse.

> If there are no connections available, then a new one would be opened, up
> to a maximum equal to the number of Zope threads.
>
> What problems/weaknesses can people see with this approach?

Problems: when you have such stuff outside the Zope, it is quite difficult to 
make it not fragile. But I didn't say "impossible". Possible, but difficult.

Weakness: What if Zope decrease threads? Why we need so much connections all 
the time, espesially if they might be payed? I think we need the connections 
to be wise and up to needs, no overkills.


On Thursday 23 October 2003 19:58, Chris Withers wrote:
> > Bad side is: connections SHOULD NOT be cacheable at all.
> Why not?

Just because. ;-) Well, why you should keep it in cache? What to do, if you 
need IMMEDIATELY remove the connection? See, when you click on "Close 
connection", it means you click on meaningless button. Dieter had some right 
explanation about the volatile attributes, which only confirms that we need 
good rework of the Zope connection handling. There is no such stuff as 
connection manager, state manager or so. Currently it is really too far what 
I expect... You might be happy because "It works somehow", but not realy 
happy "it works for sure".

-- 
Regards, Bogdan M.Maryniuck

System programmer, Forbis UAB