Does not have concurrency control (locking or optimistic) so race conditions are possible

[a3kov]

I see no sign of locking here. Session is a shared resource. To avoid losing data and to have predictable results, concurrency control is needed. In the case of Redis it means you need to use locking, so that parallel requests using same session don't overwrite each other's session data.
Google "session race condition" to get plenty of information on this topic.

The irony of the fact is using exclusive locks partly defeats the whole idea of using fast session backend such as Redis: with locking parallel requests will effectively wait in a queue. But of course this will only affect same session requests. This is one of the reasons why I think database-backed sessions are not such a bad idea after all. Atleast, when we will have pyramid_retry finally working.