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.
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.
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.
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.
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.
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.
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 forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Just store serializable data