I need to explain why carrying around entire objects in the session is a bad idea in Rails. The folks I need to explain this to are relatively new to Rails, coming from a .net background (I personally have no .net experience).
I understand the server memory usage problem that stems from storing objects rather than object ids in session. I’m trying to understand whether or not there are additional performance impacts related to transforming session data into ActiveRecord objects. I’ve got a couple of questions, and would be very happy to get any additional information I may not know enough to ask.
When Rails receives a request and retrieves the session data, does it unmarshall all of it prior to invoking the action requested? Or does it wait until session data is requested / used by the action?
When does Rails create ActiveRecord objects out of the unmarshalled session data? Asked a little differently, maybe better, if I do …
@some_var = session[:some_data]
what’s the sequence of steps Rails takes internally to create the @some_var AR object?
Is there a difference in performance between creating AR objects from session data vs. creating AR objects from table data?
I need to explain why carrying around entire objects in the session is a bad idea in Rails. The folks I need to explain this to are relatively new to Rails, coming from a .net background (I personally have no .net experience).
I understand the server memory usage problem that stems from storing objects rather than object ids in session. I'm trying to understand whether or not there are additional performance impacts related to transforming session data into ActiveRecord objects. I've got a couple of questions, and would be very happy to get any additional information I may not know enough to ask.
When Rails receives a request and retrieves the session data, does it unmarshall all of it prior to invoking the action requested? Or does it wait until session data is requested / used by the action?
The sessions is unmarshalled before your filters or actions are called.
When does Rails create ActiveRecord objects out of the unmarshalled session data? Asked a little differently, maybe better, if I do ...
@some_var = session[:some_data]
what's the sequence of steps Rails takes internally to create the @some_var AR object?
When the session gets unmarshalled it is rehydrated into the real objects that were stored in the session.
Is there a difference in performance between creating AR objects from session data vs. creating AR objects from table data?
The base64 endcoding and marshalling can be expensive and it all has to come out of the db anyway. Also problems can arrise when you store AR objects in the sessions. Associated objects and get pulled in and then remain stale or get out of sync with what is in the real db records.
I *only* store simple strings, integers, arrays and hashes in the session. It avoids a lot of problems. If you have AR models stored in the sessions and then you deploy new code the old version of the model is in the session and when it gets unmarshaled it can crap out because its not the same version of the class.
Basically tell them to only store simple object. It will avoid a ton of pain.
Thank you _very_ much for making the time to reply. I'll pass the
information along. I'm sure it will help. They're used to .net and I
understand the habit's pretty ingrained in that community, so I don't expect
overnight success, but now I've got something I can just remind them to
revisit from time to time
As a longtime .NET developer now using Rails, I can add that the
practice of storing objects in session data is a bad idea even
in .NET. Marshalling/unmarshalling an object is expensive, and as
Ezra pointed out can become "stale". Suppose one object is stored in
someone's browser session and you don't expire it for a week. Next
day you enhance your object and release a new version of your app.
User opens their browser, goes to your site, and your app will try to
unmarshall an old version of the object. Not good. This would happen
in .NET and in Rails (although it's true, there are some workarounds
in .NET that are possible, but are a pain).
More and more .NET shops are trying Rails, and I'd be anxious to hear
more about your experience so far.
Interestingly, state management in .NET and Rails is something that I
debate with my friends all the time.
.NET also has another type of state management called view state,
where data can be associated with the page or even a specific control
on the page, and is then sent back and forth between postbacks. In
fact, an ASP.NET page is one big form, so while it is inefficient from
a bandwidth perspective, it is quite a handy feature. Incidentally,
this feature also enables you to re-sort a list without hitting the
DB, which in Rails would require that you implement sorting in
JavaScript.
Take, for example, a page with an n-tiered menu system. In .NET, the
expanded state of each node in the menu system can be stored on that
node, so each node will always know how to re-render itself.
In Rails, you would have to maintain a list of expanded nodes in the
session, in order to re-render a page with everything preserved. I
used to dismiss that, arguing that you can AJAX everything in Rails to
you never need to re-render a page, but then I got flamed by the
accessibility police who kindly pointed out that AJAX has a habit of
sending screen readers into a frenzy.
Anyway, this is a bit off topic, but interesting nonetheless.
Understanding the pros and cons of each platform can only make your
own platform better.
Thanks very much for making time to reply. I definitely appreciate it.
Hearing from other .net developers will undoubtably make a much larger
impression on the team than hearing it from me!
As far as experience so far... the team is well intentioned and very
impressive wrt what they individually bring to the table. As far as the app
itself... I'm from the south. The rule is... 'if you can't say anything
nice...". I know it'll get better but I think the situation right now is
best summed up by a quote from Will Rogers (the humorist, not the TV cowboy,
Dale Rogers)...
It's not what we don't know that hurts. It's what we know that ain't true.
Thanks again for making the time to reply. I appreciate it very much!
