Forum: Ruby on Rails The true merit of non-memory based session stores

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Wes G. (Guest)
on 2006-05-08 23:17
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
Jeremy K. (Guest)
on 2006-05-08 23:58
(Received via mailing list)
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.

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
Wes G. (Guest)
on 2006-05-09 00:09
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
Paul B. (Guest)
on 2006-05-09 00:15
(Received via mailing list)
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.
Paul B. (Guest)
on 2006-05-09 00:50
(Received via mailing list)
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.
Jeremy K. (Guest)
on 2006-05-09 01:33
(Received via mailing list)
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
This topic is locked and can not be replied to.