# The true merit of non-memory based session stores **URL:** \ **Category:** Rails\ **Created:** [May 8, 2006, 9:17pm UTC](https://www.ruby-forum.com/t/the-true-merit-of-non-memory-based-session-stores/94602 "2006-05-08T21:17:42Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\ **Post date:** [May 8, 2006, 9:17pm UTC](https://www.ruby-forum.com/t/the-true-merit-of-non-memory-based-session-stores/94602/1 "2006-05-08T21:17:42Z")
All, There is an assertion in AWDWR that the in-memory session store is “too simplistic.” However, I find myself nudged in this direction by the need to keep a non-serializable model attribute available in my session and the relative pain of implementing either a custom serialization scheme for the model in question (or a custom caching mechanism so that I can store my attribute in memory). When I first read that the in - memory storage method was frowned upon, I was surprised, because in my experience, only some e-commerce shopping cart apps _sometimes_ handle session persistence. Anyone have any thoughts on the validity of using an in-memory session store? Obviously, it’s much faster as well. Thanks, Wes ---
**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\ **Post date:** [May 8, 2006, 9:58pm UTC](https://www.ruby-forum.com/t/the-true-merit-of-non-memory-based-session-stores/94602/2 "2006-05-08T21:58:54Z")
On May 8, 2006, at 12:17 PM, Wes G. wrote: > However, I find myself nudged in this direction by the need to keep a > non-serializable model attribute available in my session and the > relative pain of implementing either a custom serialization scheme for > the model in question (or a custom caching mechanism so that I can > store > my attribute in memory). Perhaps this need is easier to eliminate than your session store. > When I first read that the in - memory storage method was frowned > upon, > I was surprised, because in my experience, only some e-commerce > shopping > cart apps _sometimes_ handle session persistence. > **[Shared-nothing architecture](https://en.wikipedia.org/wiki/Shared_nothing_architecture)** > > A shared-nothing architecture (SN) is a distributed computing architecture in which each update request is satisfied by a single node (processor/memory/storage unit) in a computer cluster. The intent is to eliminate contention among nodes. Nodes do not share (independently access) the same memory or storage. One alternative architecture is shared everything, in which requests are satisfied by arbitrary combinations of nodes. This may introduce contention, as multiple nodes may seek to update the ... You could come up with some session affinity scheme to direct users to the server which has their data in memory. NOT doing that is certainly easier 🙂 Just store serializable data and be done with it. Best, jeremy ---
**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\ **Post date:** [May 8, 2006, 10:09pm UTC](https://www.ruby-forum.com/t/the-true-merit-of-non-memory-based-session-stores/94602/3 "2006-05-08T22:09:02Z")
It makes sense that an in-memory session store is a problem in a multi-server scenario, because then you need some kind of session affinity solution. Wes Wes G. wrote: > All, > > There is an assertion in AWDWR that the in-memory session store is “too > simplistic.” > > However, I find myself nudged in this direction by the need to keep a > non-serializable model attribute available in my session and the > relative pain of implementing either a custom serialization scheme for > the model in question (or a custom caching mechanism so that I can store > my attribute in memory). > > When I first read that the in - memory storage method was frowned upon, > I was surprised, because in my experience, only some e-commerce shopping > cart apps _sometimes_ handle session persistence. > > Anyone have any thoughts on the validity of using an in-memory session > store? > Obviously, it’s much faster as well. > > Thanks, > Wes ---
**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\ **Post date:** [May 8, 2006, 10:15pm UTC](https://www.ruby-forum.com/t/the-true-merit-of-non-memory-based-session-stores/94602/4 "2006-05-08T22:15:18Z")
How can you have a “shared nothing” architecture for a web app that relies on a database? All you data is stored in the database, and therefore storing all your sessions in the database just makes your application more dependant on the database server. ---
**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\ **Post date:** [May 8, 2006, 10:50pm UTC](https://www.ruby-forum.com/t/the-true-merit-of-non-memory-based-session-stores/94602/5 "2006-05-08T22:50:30Z")
affinity solutions don’t seem to be that hard. If you have a multi-server scenario, in most cases you will have a hardware load balancer in front of the web/app servers. It is trival to configure a load balancer to make sessions sticky, using IP or by checking a cookie. This allows you to cache commonly used data like user credentials (who is logged in and what roles/permissions do they have) at the app server level. This moves some of the load to the app server tier, where it is easier to scale. Scaling at the DB layer is tricky. ---
**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\ **Post date:** [May 8, 2006, 11:33pm UTC](https://www.ruby-forum.com/t/the-true-merit-of-non-memory-based-session-stores/94602/6 "2006-05-08T23:33:42Z")
On May 8, 2006, at 1:10 PM, Paul B. wrote: > How can you have a “shared nothing” architecture for a web app > that relies on a database? All you data is stored in the database, > and therefore storing all your sessions in the database just makes > your application more dependant on the database server. This distinction is important, but academic. (If you use NFS to serve your app’s files to diskless web nodes, is that still shared nothing? No, not strictly. However, that “no” is functionally useless.) What’s important (to me) is how we think about state in a stateless world (HTTP) and how that thinking has led to abstractions – like sessions – which give us nice, consistent ways to encapsulate whatever state-sharing that is required. Best, jeremy