Clojurians Log v2

Interesting, do you have more details about that?

In practice, session data is rarely used in a manner where this would be an issue, and not all session stores (encrypted cookies for example) can support an atomic “swap”. Where concurrency is required, it’s often better to store an identifier in the session that links to a database that supports atomic updates.

Any details about how exactly this could happen (possible with some code pointers)? 🙂

Two handlers overlap and want to write at the same time. So A reads session, B reads session, B writes session, A writes session. In this case, B’s changes would be overwritten by A’s changes.

Ah, I see. Thanks!

For certain types of session store this is unavoidable, as not all stores support atomic updates.

Thanks for the reply. Makes sense.