On Nov 11, 2006, at 5:35 PM, Greg H. wrote:
the first time I guess)
- CON - Some minimal extra complexity in the code (i.e. for each
request what has to be done)
- ADV - Perhaps faster when do you want to pull back a list of
Right but keep in mind that the session gets read from and then
written to the db on every request anyways. So the session is already
going to be read from the db at the beginning of each request. If you
set the user_id column of the session object in a before filter it is
no extra db overhead because the session was already read from the
db. Then at the end of the request, the session has to be written
back out to the db anyways so setting the user_id field when this
happens does not create extra db queries if done right.
Option 2 - Use marshalled session data (stored in the data column
in session table)
- ADV - Can easily add userID to the session when performing normal
authentication/authorisation checks, so no additional overhead
( e.g. find session via AR then update)
- CON - Perhaps slower to iterate through list, BUT the only time
one would need to do this would be for someone requesting a list of
active users logged on.
The real problem with this way of doing things is memory and cpu
time. Lets say you keep your sessions cleaned out pretty regularly.
So assume 200 sessions laying around at any one time(rails makes a
lot of sessions entries so this number is conservative). So each of
these 200 sessions now need to be loaded into memory and unmarshaled
to see the user_id inside the session. That means 200 times however
much data is in each of those sessions. This will end up making your
app leak memory or at least taking a lot more then it needs. Plus it
will burn your cpu while it unmarshalls and un base64 encodes all
that session data.
I kinda thought Option 2 may be better as it avoids an extract
database hit per request, in return for a slower “get me active
sessions” call which is only occasionally when requested by a user.
I think that you can add a user_id column to the sessions model and
not incur anymore database queries then the session is already doing
without it. Its just a matter of writing and reading the user_id from
the Session model instead of as a hash in its data part.
That should NEVER be the case. Yes it is by default, but you should be
see WHEN that session record was created or last touched. The problem
So my previous note about checking when it was last updated can become
problematic because it requires constantly writing to that table. Then
again, maybe this last one is just me being overly cautious.
– Ezra Z.
– Lead Rails Evangelist
– [email protected]
– Engine Y., Serious Rails Hosting
– (866) 518-YARD (9273)