This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-30
Channels
- # admin-announcements (1)
- # announcements (1)
- # babashka (8)
- # bristol-clojurians (1)
- # calva (36)
- # clojure (115)
- # clojure-europe (5)
- # clojure-italy (4)
- # clojure-nl (3)
- # clojure-norway (3)
- # clojure-uk (161)
- # clojuredesign-podcast (3)
- # clojurescript (71)
- # core-async (34)
- # cursive (26)
- # datomic (43)
- # docker (2)
- # emacs (24)
- # figwheel-main (1)
- # fulcro (36)
- # graalvm (7)
- # immutant (2)
- # jackdaw (1)
- # jobs (2)
- # leiningen (8)
- # luminus (5)
- # off-topic (29)
- # onyx (1)
- # other-languages (5)
- # pathom (6)
- # pedestal (3)
- # reagent (11)
- # ring (8)
- # shadow-cljs (42)
- # spacemacs (17)
- # specter (6)
- # tools-deps (80)
- # videos (1)
Hey, I noticed that ring.middleware.session is not thread-safe, and so a long-running http request could overwrite the session with stale data. Is anyone concerned about this, or do people generally write their own session implementations that deal with this?
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.
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.
For certain types of session store this is unavoidable, as not all stores support atomic updates.