Rails - Mar 2008 - Cookie-based session store - can it get you in trouble?

All,

I recently moved to Rails 2.0 on one of my projects, and was surprised
and interested to find out that the new session store is client
cookie-based.

I''m skeptical about DHH''s claim that it will be "zero
maintenance."

I have definitely run into bugs/mistakes that I''ve introduced into my
app. where some piece of pre-existing session data causes an
unwanted/unintended effect after a change.  Usually, these issues
resolve themselves, but in some infrequent cases, the easiest method of
fixing it is to shut down the app., clear out some session data, and
restart, ensuring that no problematic "old" session data is present.

Obviously, this kind of recovery won''t be very easy if the session data
is client-side.

I have a few questions:

1) Has anyone considered this as an issue with the client - side session
cache approach?

2) Has anyone created a special action that might force the cleanup of a
session, in order to handle cases where cleaning the session might be
necessary?

3) Also, it just occurred to me that I don''t quite understand the claim
that this method is "a lot faster than traditional session stores."
So, now, instead of storing the session data on the same server and
retrieving it over a high-speed network, the session data gets
transmitted on each request/response as a cookie?  How is that faster?

Any thoughtful responses are appreciated.

Thanks,
Wes
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 15 Mar 2008, at 19:53, Wes Gamble wrote:
> 3) Also, it just occurred to me that I don''t quite understand the
> claim
> that this method is "a lot faster than traditional session
stores."
> So, now, instead of storing the session data on the same server and
> retrieving it over a high-speed network, the session data gets
> transmitted on each request/response as a cookie?  How is that faster?
Because if you use the session for what it''s supposed to be used (i.e.
as little as possible, a user id and a flash should suffice), the  
total length of all session data probably won''t even surpass the  
hashed value in the cookie that is used with serverside stores.


Best regards

Peter De Berdt


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Wes Gamble wrote:
>
> 1) Has anyone considered this as an issue with the client - side session
> cache approach?
>
> 2) Has anyone created a special action that might force the cleanup of a
> session, in order to handle cases where cleaning the session might be
> necessary?
If you change the secret used for the cookie store that will
invalidate all sessions.
>
> 3) Also, it just occurred to me that I don''t quite understand the
claim
> that this method is "a lot faster than traditional session
stores."
> So, now, instead of storing the session data on the same server and
> retrieving it over a high-speed network, the session data gets
> transmitted on each request/response as a cookie?  How is that faster?
>
With all the other stores, the rails process has to do something to
get the session data, whether it''s open a file, query the database or
talk to a memcached server. That''s going to take soe time. Not much,
but it all adds up. With the cookie store, the session data just
arrives with the request. Sure it''s an extra couple of hundred bytes
on each request but I rather suspect that it doesn''t make a huge
amount of difference, as the problem here is more likely to be the
latencies involved rather than the time it actually takes to move the
data (which, as Peter said, is typically small)

Fred
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> Because if you use the session for what it''s supposed to be used
(i.e.
> as little as possible, a user id and a flash should suffice), the
> total length of all session data probably won''t even surpass the
> hashed value in the cookie that is used with serverside stores.
I agree wholeheartedly with the sentiment about "using the session for 
what it''s supposed to be used for," but I have to say that maybe
it''s
just me, but I come up against requirements in my app. all the time that 
require cross-request, non-persitent storage of state.  Which is not to 
say that I''m into abusing the session, but it tends to be a little less
trivial than just a user_id and a flash.

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---