The current implementation of sessions for rails with jruby uses the
java web container session to store the session data. At first blush,
this seems like a reasonable thing to do. However, there seem to be
issues. In particular, since the session data is kept in memory in the
JVM, it never needs to be marshaled/unmarahsled. This seems (though of
course, I could be wrong) interact badly with rails trying to reload
classes. What I think is see is rails complaining about classes of
objects in the session. The classes of those objects has an older
object_id from the classes that are reloaded. In a case where the store
is serialized, there's always a marshal/unmarshal pass that means the
session objects are upgraded to the new class.
Are you sure sessions are kept in memory? What Java app server are you using for JRuby/Rails? Session storage is usually configurable (memory/disk/database) for app servers.
Java specifies that objects stored in HttpSessions implement the Serializable interface. In fact it lays out marshalling of an object’s state for Java.
You might want to send your question to the JRuby mailing list, because it is most likely a limitation of Classloading within Java/JRuby and not a flaw in Rails at all.
I assume you're using the "rails integration" module that allows you to
run a Rails app as a WAR file.
It seems odd that there would be a problem storing the Rails session in
the Java app server session, since Rails itself provides an in-memory
store to use in the same way. If you can narrow down what's actually
the problem, maybe we can figure out how to resolve it.
The other option would be to see if it continues to happen in
production mode, where classes aren't mutated and reloaded as much (or
at all?).
As Charlie suggested (and I had thought to do before, but was too
tired), everything works fine if I change the environment from
development to production so that it doesn't do any reloading around
each request.
I forgot about the rails CGI:Session::MemoryStore and I actually
figured it might serialize anyway. But it doesn't.
And it has exactly the same problem.
So it's not solely an issue with the servlet session but it's of more
interest to "us" than the core rails folks since next to nobody is
using the memory store, I expect.
From the pure rails side, is it a bug that MemoryStore may not work
with module reloading, e.g., development mode, or a "don't do
that"/"won't fix" kind of thing?
