Rails core - Jan 2007 - sessions on rails on jruby with web-container integration

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.

Any comments or suggestions?


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

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.

On 1/26/07, aptosca <steven.parkes@gmail.com>
wrote:
>
>
> 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.
>
> Any comments or suggestions?
>
>
> >
>

-- 
Thanks,
-Steve
http://www.stevelongdo.com

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

On Jan 26, 6:02 pm, "aptosca" <steven.par...@gmail.com>
wrote:
> The current implementation of sessions for rails withjrubyuses 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.
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?).

- Charlie


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

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?


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