per @aaron
It currently does a get() before set(), which I think has race conditions? It's not necessary for session storage, though.
per @aaron
It currently does a get() before set(), which I think has race conditions? It's not necessary for session storage, though.
So, this isn't required for session storage. I'm going re-tag it, but I don't think it should block.
While having an atomic incr() method would certainly be nice, this task doesn't make sense to me for two reasons:
Overall, BagOStuff is overloaded and under-specified. We should introduce new, more narrow interfaces that provide more guarantees about the semantics of the methods they define. An interface that is designed to fit any key-value-store will lack the guarantees that would make it useful in any but the most trivial use cases.
Anything that can be atomic should be, or it gets kind of useless, for BagOStuff. The redis issue is a bug and should be fixed (infinite TTL stuff can get stuck). If a backend can't do incr() right, then it should implement a simpler interface. I agree about extra interfaces or something to narrow down what kind of operations a backend can easily do. That's part of why I made WANObjectCache it's own layer (among other reasons like cache-specific semantics and related useful assumptions). I keep thinking about migrating the main stash to a simpler interface, though I've never got around to it.
Removing myself as assignee because I am not currently working on this, and am not scheduled to in the near future. I would not object to working on it on the future if plans and priorities allow, but I do not want to give a false impression of status or discourage anyone else from taking it over.