[storm] suspected bug in caching behavior
Andreas Kopecky
andreas.kopecky at meduniwien.ac.at
Mon Nov 10 18:27:08 GMT 2008
Hello storm mailing list,
This is my first post here so please forgive me if this is
a.) not the right place for this kind of message or
b.) this mail is not in the right form
Subject basically says it all - i think i encountered faulty/buggy
behavior in the way Storm (or rather storm.store.Store) handles
caching of ObjectInfo objects.
Bug description:
Updates to Storm object don't always reset the _checkpoint_state of
this objects ObjectInfo.
Reason:
(Just a brief preface to make sure i get Storm mechanics right)
Objects in a Storm Store are cached on two different levels. At first
their ObjectInfo is stored in Store._cache, secondly a copy of this is
also stored in Store._alive (a WeakValueDictionary).
Whenever an object is loaded via Store.find, Store._load_object
is called, which (if the object is loaded the first time)
instantiates an ObjectInfo object and puts it into Store._cache and
Store._alive (via Store._add_to_alive). Loading a cached object in
Store.find - in contrary to what would be expected - does NOT ask
Store._cache but rather Store._alive. When a transaction boundary
is reached (on either Store.commit or Store.rollback) the cache
is purged via Store.invalidate. HOWEVER, the Store._alive dict
stays untouched until it is cleared by garbage collection.
Result:
When you load an object that has been cached previously and happen
to be faster then the garbage collection you might get an artifact
of an ObjectInfo object which is still in a state that is no longer
in sync with the database.
Proposed fixes:
- clear Store._alive in Store._invalidate
or
- ask Store._cache if an object is - in fact - cached
Some others are possible too but i guess you sure got more insight
into Storm then i do :)
- regards
Andreas Kopecky
More information about the storm
mailing list