A little bit of history...
We have zope as an application server for heavy loaded tech process. We
have high peaks of load several times a day and my question is about how
can we can avoid unused connections to remain in memory after peak is
passed?
Before ZODB-3.4.1 connection pool was fixed
В Чтв, 29/12/2005 в 11:30 +0100, Florent Guillaume пишет:
A little bit of history...
We have zope as an application server for heavy loaded tech process. We
have high peaks of load several times a day and my question is about how
can we can avoid unused connections to remain in memory
A little bit of history...
We have zope as an application server for heavy loaded tech process. We
have high peaks of load several times a day and my question is about how
can we can avoid unused connections to remain in memory after peak is
passed?
Before ZODB-3.4.1 connection pool was fixed
В Чтв, 29/12/2005 в 12:27 +0100, Florent Guillaume пишет:
If you see many RDB connections, then it's a RDB problem and not a ZODB
problem. Something not releasing RDB connections quick enough, or
leaking RDB connections.
Not agree. Can you answer the question? Does self.all.remove(c)
[??? ? ?]
Hi. A little bit of history... We have zope as an application server for
heavy loaded tech process. We have high peaks of load several times a day
and my question is about how can we can avoid unused connections to
remain in memory after peak is passed? Before
[Florent Guillaume]
...
The self.all.remove(c) in _ConnectionPool attempts to destroy the
connection.
Nope, it's simply getting rid of a weak reference that no longer serves a
purpose, to avoid unbounded growth of the .all set in case of ill-behaved
application code, and to speed Python's
...
[Florent Guillaume]
The self.all.remove(c) in _ConnectionPool attempts to destroy the
connection. If something else has a reference to it once it's closed,
then that's a bug, and it shouldn't. It should only keep a weak
reference to it at most.
[EMAIL PROTECTED]
But it's nonsense!
Oops! I sent this to zope-dev instead of zodb-dev by mistake.
[EMAIL PROTECTED]
Not agree. Can you answer the question? Does self.all.remove(c) mean
that we WANT to destroy connection instance?
[Tim Peters]
It means that _ConnectionPool no longer has a reason to remember
anything about that
[Syver Enstad]
I have recently upgraded from ZODB 3.2 to 3.5.1. After doing this I
notice that ZEO throws exceptions on commiting a transaction for certain
types of Persistent classes.
...
I was able to create a small self-contained test case from this description,
and opened a Collector
Tim Peters wrote at 2005-12-29 11:28 -0500:
...
Or there are no strong reference to `obj`, but `obj` is part of cyclic
garbage so _continues to exist_ until a round of Python's cyclic garbage
collection runs.
And this is *VERY* likely as any persistent object in the cache
has a (strong, I
[Tim]
...
Or there are no strong reference to `obj`, but `obj` is part of cyclic
garbage so _continues to exist_ until a round of Python's cyclic garbage
collection runs.
[Dieter Maurer]
And this is *VERY* likely as any persistent object in the cache has a
(strong, I believe) reference to
HelloI have recently jumped into python and ZODB . I am quiet familar to syntax and everything but there is one Issue . when we create a .fs file or say data.fs and saves in it some objects.If we open this file in notepad or other editior. It shows the data about objects everything its name
On 12/29/05, Monica chopra [EMAIL PROTECTED] wrote:
I have recently jumped into python and ZODB . I am quiet familar to syntax
and everything but there is one Issue . when we create a .fs file or say
data.fs and saves in it some objects.If we open this file in notepad or
other editior. It
13 matches
Mail list logo
