[storm] suspected bug in caching behavior

James Henstridge james at jamesh.id.au
Tue Nov 11 08:34:31 GMT 2008


On Tue, Nov 11, 2008 at 4:26 PM, Andreas Kopecky
<andreas.kopecky at meduniwien.ac.at> wrote:
> Hi,
>
> James Henstridge schrieb:
> <snip />
>  >
>  > This sounds a bit like https://bugs.launchpad.net/storm/+bug/277095
>  > which has been fixed on trunk since the 0.13 release.
>  >
>  > If you have the time, would you mind trying to reproduce the bug with
>  > the development version of Storm?  Alternatively, you could try
>  > applying the changes from
>  > http://bazaar.launchpad.net/~storm/storm/trunk/revision/271 to the
>  > 0.13 release and see if that helps.
>
> Thanks for the quick answer. Bug description does sound quite familiar
> yes. Am i right to assume that the fix you suspect is
>
> 270. By  Thomas Herve  on 2008-10-02
>
>     Reset checkpoint states of variables when updating a field with
>     a lazy value:
>     this fixes a problem with an update reverting a field value to
>     a previously cached value.
>
> If yes i will patch my 0.13 with the changes of that revision and see
> how it works out.

That is one of the revisions that was merged in r271 of Storm's trunk.
 The bazaar.launchpad.net link shows the related changes that were
merged with it, and has a "diff" link at the top.


> For completeness a quick guide to reproduce this behavior:
>
> make a storm object with field bar, value foo.
>  - load this object and update bar to fuu
>  - load object again update bar to foo again
>  - load object a third time, update to fuu a second time
> if you are faster then garbage collection the value will
> not be changed but stay at 'foo' because you get an artifact
> of ObjectInfo with a faulty _checkpoint state.

Are you using multiple connections/stores to produce this behaviour?
The test case for this problem used 2 stores, but it'd be interesting
to know if the problem can be reproduced with a single store.


> Sounds very much like the bug you sent me back yet i am not so
> sure if it is good to fix that via a reset of _checkpoint_state.
>
> The bug lies within the usage of WeakValueDictionary - or rather
> not clearing it over transaction boundaries while using it as
> de facto cache

Not clearing the alive list is intended behaviour.  The
checkpoint_state bit obviously wasn't :)


> - regards
> Andreas Kopecky
>
> P.S. On a side note i just love Storm - we are doing a rather big Zope
> project here and i replaced a ZODB implemenation of the datamodel with
> Storm 1.5 years into the project and it just worked like a charm - just
> wanted to tell you ;)

That's nice to hear.  If you have ideas for improvements to the Zope
integration API, please tell us (either on the list or the bug
tracker).

James.



More information about the storm mailing list