Dieter Maurer wrote:
The pickle size is a *VERY* rough estimation (probably wrong
by a factor of 5 to 15)
But, as you point out, much better than a hard coded "1" ;-)
We probably would get a much better estimation using
"PySizer" but probably at a significantly higher cost.
Right, I guess
Dieter Maurer wrote:
I have put an enhancement proposal at
http://www.zope.org/Wikis/ZODB/VolatileAttributeLifetimeGarantee
It allows applications to declare that they need for
some (so called sticky) objects a garanteed lifetime for their
volatile attributes that extends until at least the
Dieter Maurer wrote:
Pascal Peregrina wrote at 2006-10-5 15:45 +0200:
It would be interesting to have a solution for pure Read-Only Zope instances
(using a ZEO architecture, but it might work with a local FileStorage) to
allow several requests to be served from the same "Connection object",
Jim Fulton wrote:
Dmitry Vasiliev wrote:
Jim Fulton wrote:
Thoughts? Is anyone willing to help out? Anybody interested in a
ZODB Doc Day?
I'll ready to help with the docs. I guess we'll can made some minor
API/code cleanup at the same time. But I think "ZODB Doc Days" is
unnecessary.
The
I've created a proposal:
http://www.zope.org/Wikis/ZODB/DecouplePersistenceDatabaseAndCache
for simplifying and decoupling the persistence and cache architectures.
I've been thinking about this for quite some time. In fact, the ability to
subclass
weakref.ref objects that appeared in Python
Jim Fulton wrote at 2006-10-6 12:10 -0400:
> ...
>I'm a little uneasy about baking this policy so deeply into
>the infrastructure. I wonder if the use case can be handled
>another way.
>
>A persistent object can override _p_deactivate. For example:
>
> def _p_deactivate(self):
> pass
Jim Fulton wrote at 2006-10-6 12:21 -0400:
> ...
>> We would have a use case for this, too.
>
>We've started moving toward just using a single application thread per process
>(with many processes). There isn't really much advantage in running multiple
>threads if you have multiple processes.
Apa
Dieter Maurer wrote:
Jim Fulton wrote at 2006-10-6 12:10 -0400:
...
I'm a little uneasy about baking this policy so deeply into
the infrastructure. I wonder if the use case can be handled
another way.
A persistent object can override _p_deactivate. For example:
def _p_deactivate(self):
Chris Withers wrote at 2006-10-6 11:15 +0100:
> ...
>Cool, I didn't know that, but of course it makes sense, unless you have
>a storage that doesn't use pickles...
>
>How would you cater for that?
Not at all.
They must use a special "Connection" and I am only concerned with
standard connections.
Dieter Maurer wrote:
Jim Fulton wrote at 2006-10-6 12:21 -0400:
...
We would have a use case for this, too.
We've started moving toward just using a single application thread per process
(with many processes). There isn't really much advantage in running multiple
threads if you have multiple
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
> Dieter Maurer wrote:
>> Jim Fulton wrote at 2006-10-6 12:21 -0400:
>>> ...
We would have a use case for this, too.
>>> We've started moving toward just using a single application thread
>>> per process
>>> (with many processes)
Jim Fulton wrote at 2006-10-6 15:08 -0400:
> ...
>>> You could implement your sticky attribute at the application level:
>>>
>>>
>>> def _p_deactivate(self):
>>> if getattr(self, '_p_sticky', False):
>>>return
>>> Persistent._p_deactivate(self)
>>>
>>> You could prov
Jim Fulton wrote at 2006-10-6 15:13 -0400:
>Dieter Maurer wrote:
>> Jim Fulton wrote at 2006-10-6 12:21 -0400:
>>> ...
We would have a use case for this, too.
>>> We've started moving toward just using a single application thread per
>>> process
>>> (with many processes). There isn't really
Dieter Maurer wrote:
Jim Fulton wrote at 2006-10-6 15:08 -0400:
...
You could implement your sticky attribute at the application level:
def _p_deactivate(self):
if getattr(self, '_p_sticky', False):
return
Persistent._p_deactivate(self)
You could provide any po
Recently, I reported:
Dieter Maurer wrote at 2006-9-24 16:28 +0200:
>ATT: Crosspost. Please reply to "zodb-dev@zope.org" ("Reply-To" header set).
>
>
>We recently have had a problem that seems to indicate a small
>hole in ZODB (3.4) transaction management.
> ...
I may have found the cause for thi
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
Dieter Maurer wrote:
Jim Fulton wrote at 2006-10-6 12:21 -0400:
...
We would have a use case for this, too.
We've started moving toward just using a single application thread
per process
(with many processes)
Dieter Maurer wrote:
...
The only benefit of multiple threads is that it is somewhat
less likely that expensive requests will block inexpensive ones.
Multiple threads can share resources such as main memory and
a common cache (proposed by the original poster).
If there is only one thread, the
Jim Fulton wrote at 2006-10-6 16:02 -0400:
>Dieter Maurer wrote:
>> Jim Fulton wrote at 2006-10-6 15:08 -0400:
>>> ...
> You could implement your sticky attribute at the application level:
>
>
> def _p_deactivate(self):
> if getattr(self, '_p_sticky', False):
>
Jim Fulton wrote at 2006-10-6 16:18 -0400:
>Dieter Maurer wrote:
>...
>>> The only benefit of multiple threads is that it is somewhat
>>> less likely that expensive requests will block inexpensive ones.
>>
>> Multiple threads can share resources such as main memory and
>> a common cache (proposed
Dieter Maurer wrote:
Jim Fulton wrote at 2006-10-6 16:02 -0400:
Dieter Maurer wrote:
Jim Fulton wrote at 2006-10-6 15:08 -0400:
...
You could implement your sticky attribute at the application level:
def _p_deactivate(self):
if getattr(self, '_p_sticky', False):
retur
Dieter Maurer wrote:
Jim Fulton wrote at 2006-10-6 16:18 -0400:
Dieter Maurer wrote:
...
...
We abused Zope a bit and have build a desktop application with it.
One of the main critiques of our customers is too high memory
consumption. Many have computers with 256 MB memory and
they
21 matches
Mail list logo
