[ZODB-Dev] Unexpected behavior of a volatile property

[Michel Pelletier]

On Thu, 11 Oct 2001 11:23:40 -0500
 "Patrick K. O'Brien" <pobrien@orbtech.com> wrote:
> I'm seeing some behavior I don't understand. I'm playing around with the
> sample application I'm creating. As part of this, I'm generating some test
> objects. When I generated 5000 of them, assigning a volatile property
> (_v_key), the first 1730 objects "lost" this property -- hasattr(object,
> '_v_key') fails -- the remaining objects all have the property. How can this
> happen?

_v_ attributes are lost when the object is deactivated, this means when the object is removed from memory.  Probably what happened was, you started creating so many objects that ZODB began deactivating the "old" ones.  These deactivated objects lost their _v_ attributes.  When you went back to look at them, you reactivated them, but they, now having been deactivated and reactivated, don't have _v_ attr.  The "new" objects that never got deactivated, continue to have their volatile attributes.

> This is during the session where the objects are created, not in
> between sessions (where you would expect the volatile property to be ...
> volatile).

There is no concept of "session" that defines the lifetime of volative attr.  Volative attrs have no predictable lifetime.  An object could get deactivated immediately after it was created, if the right conditions exist.  Volatile attributes are only useful as a quick "cache" of some possibly expensive, but trivially recreatable data.  They're probably not as useful as you think they are.

<snip>

> def new():
>     """Return a random integer for use as a key value.
>     The return value can range from -2147483647 to 2147483647."""
>     global choice, randint
>     maxint = 2147483647

BTW, you might want to look into the sys.maxint value on your platform, it might make this code more flexible.

> Can anyone explain what is going on? I didn't expect a _v_ property to be
> volatile within a session, I just expected it to not be made persistent and
> to not trigger conflicts. Am I mistaken?

Once again I'm not sure what you think a session is, and I didn't really grok your code.  Does my explanation above help?

-Michel