Rails - May 2006 - The true merit of non-memory based session stores

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

-- 
Posted via http://www.ruby-forum.com/.

On May 8, 2006, at 12:17 PM, Wes Gamble 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.
http://en.wikipedia.org/wiki/Shared_nothing_architecture

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

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 Gamble 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

-- 
Posted via http://www.ruby-forum.com/.

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.

On 5/8/06, Jeremy Kemper <jeremy@bitsweat.net>
wrote:
>
> On May 8, 2006, at 12:17 PM, Wes Gamble 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.
>
> http://en.wikipedia.org/wiki/Shared_nothing_architecture
>
> 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
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060508/aab4eff2/attachment.html

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.

On 5/8/06, Wes Gamble <weyus@att.net> wrote:
>
> 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 Gamble 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
>
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060508/af1ccc8c/attachment.html

On May 8, 2006, at 1:10 PM, Paul Barry 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