[Zope-DB] Orace Saga again (Re: Saga continues)
Bo M. Maryniuck
b.maryniuk at forbis.lt
Fri Oct 24 13:20:52 EDT 2003
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
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
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
More information about the Zope-DB