Potential (minor?) problem in WACache

[GoogleCodeExporter]

Presumably keysByObject and objectsByKey are supposed to be symmetrical in
that there should be an entry for each key/object pair in both dictionaries.

However, in cases where an object that compares #= to another object
already in the cache, is added there is a unique entry in the objectsByKey
dictionary , because the keys are guaranteed to be unique, but when the
object is stashed in the keysByObject dictionary the existing #= object's
entry is overridden. As a result the key for that particular object will be
lost from the keysByObject dictionary. In other words there two entries for
the 'same' object in objectsByKey, but only one entry for the object in
keysByObject.

I noticed this with a WAMimeDocument that was stored in the cache while
debugging the GemStone version of the #reap algorithm, where the
objectsByKey is scanned and an attempt is made to remove the corresponding
entry from the keysByObject, but when the second occurrence is hit, the
entry isn't found in the dictionary.

I'm not sure what would happen in an app when a document isn't found, so
it's not clear how serious this bug is.

Original issue reported on code.google.com by henrichs...@gmail.com on 28 Dec 2009 at 8:12

[marschall]

This is how things are in 3.2 which I believe addresses the issue:

• Things that are mapped bidirectionally, mapping the same value to multiple keys will raise an error:
  • request handlers in WADispatcher
  • request handlers in WARegistry (not actually used)
• Things that are mapped unidirectionally:
  • sessions in WAApplication
  • document handlers in WASession
  • continuations in WASession