Jim Fulton wrote at 2006-10-9 15:04 -0400:
...
To make cache garbage collection as fast as possible,
I have proposed to actually store the sticky information in the
C object structure.
I don't like the idea of adding that overhead to every
persistent object just for this use case. OTOH, we
Jim Fulton wrote:
Chris Withers wrote:
Jim Fulton wrote:
- I wonder if an argument could be made than we shouldn't
implicitly deactivate an object that has been accessed in a
a transaction while the transaction is still running.
Would this prevent ZODB from ever promising not to use more
Jim Fulton wrote:
- I wonder if an argument could be made than we shouldn't
implicitly deactivate an object that has been accessed in a
a transaction while the transaction is still running.
Would this prevent ZODB from ever promising not to use more than a
certain amount of memory?
The
Chris Withers wrote:
Jim Fulton wrote:
- I wonder if an argument could be made than we shouldn't
implicitly deactivate an object that has been accessed in a
a transaction while the transaction is still running.
Would this prevent ZODB from ever promising not to use more than a
certain
Dieter Maurer wrote:
Jim Fulton wrote at 2006-10-6 16:55 -0400:
...
As explained in the proposal:
We have 3 use cases for volatile attributes:
I didn't ask why you use volatile attributes.
I asked why _p_sticky needs to be stored on each instance,
since it is set at the class level.
It
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
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
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):
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
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):
return
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 next
transaction
| Feedback is welcome -- either in the Wiki or here.
I've seen an informal version of this by Dieter on a mailing list
somewhere (might even have been this list) ages ago and even thought
that it was already implemented. I really like the proposal, +1 on it.
--
Sidnei da Silva
Enfold Systems
Sidnei da Silva wrote at 2006-9-29 22:13 -0300:
| Feedback is welcome -- either in the Wiki or here.
I've seen an informal version of this by Dieter on a mailing list
somewhere (might even have been this list) ages ago and even thought
that it was already implemented.
It is implemented in our
13 matches
Mail list logo
