On Feb 3, 9:21 am, Eric Lavigne <[email protected]> wrote: > With the same issue in mind, I propose design 3. Like design 1 except > (ref {}) instead of (atom {}) because I may want to coordinate changes > between the session and some other transaction-aware state.
Sessions can be implemented with many storage engines, and not all of them will have transactions. Even those that do support transactions, such as SQL databases, do not tie in with Clojure's STM mechanism, so making the session storage a ref would only work for in-memory session storage. In my view, we need to take a lowest-common-denominator approach: if two threads try to write the same session data at the same time, then the last one to write wins. This approach will work with every sort of storage engine, and will be sufficient for most session uses. Should something more fine grained be required, a value can be added to the session that references a more sophisticated concurrency primitive. - James -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en
