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
Hello 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 shows the data about objects everything its name
[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) refer
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 bel
[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 i
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 a
...
[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 nonsens
[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.
[EMAIL PROTECTED]
> Not agree. Can you answer the question? Does self.all.remove(c) mean that
> we
[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 cy
[??? ? ?]
> 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
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.
Here is the traceback.
File "/usr/lib/python2.4/site-packages/transaction/_transaction.py",
line 389, in commit
self
В Чтв, 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.
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 size
В Чтв, 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 memo
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 size
15 matches
Mail list logo
