IMO it's on the user at that point. Don't muddle yourself with
details like that when it's their own problem and something that would
require (possibly depending on how you go about it) significant code
changes that could drastically affect performance.
Depending on how you go about it anyways, normally you would hit the
database everytime anyways and later with some clever side jobs to
pull and commit and update cached records later (or other ways it
really depends on the developer,) why not just use the ActiveRecord
object you pull and show their name? There are cases where you
wouldn't do that but such as a userless site that just stores their
name in a cookie to preference the site but you can't really control
that situation at all.
What I am saying is there are several ways you can go about it, one is
to switch to ActiveRecord sessions and add an extra key ("username")
that is only used to find and delete sessions when a user updates
their record, this would kill all possible sessions but adds extra
overhead in terms of the username and even extra overhead in terms of
ActiveRecord (but then again this is more secure and you could even
get clever and pull from Memcached and delay the commit and memcached
update with delayed_job reducing impact on the user.)
The third way would be to just update the session when you pull their
record from ActiveRecord based on their user_id in the session which
is just as well the same as just using the ActiveRecord object, except
in that case you reduce your code count a littlebit because then you
don't need to update the session.
Maybe somebody else has better ideas but this is what comes up in my head.