Ashish Sahni wrote: >> 1. Implement Java serialization in JRuby objects to use Ruby's >> marshalling format on the way in and the way out. This is problematic >> since on the receiving end the session is unlikely to have access to a >> runtime in which to restore itself. Until we can completely detach a >> live object from a given runtime, this is out of reach. >> 2. Implement an alternative app server session store that saves >> marshalled content (as a String or byte[]) in the session rather than as >> individual attributes. This would serialize fine, and the Rails app on >> the other end would know how to reconstitute it. However, it would be a >> performance hit (as would the DB-based session) since it would have to >> marshal and unmarshal the session every time. >> > Aren't #1 and #2 essentially the same under the covers - in #1 its > java's serialization at the surface > and jruby's marshalling implementation that really doing the work and in > #2 it's a more direct call > to the jruby marshalling system ?
Well, kinda. In the first case, we expect objects to be passively marshaled, which means we need to be able to passively re-attach them to runtimes on the other side of the cluster. In the second case, we avoid the reattaching headaches by actively marshaling objects into Java's session so that it's completely serializable (essentially a big byte[] or String). But yes, in both cases it uses Ruby's marshaling capabilities. _______________________________________________ Jruby-extras-devel mailing list [email protected] http://rubyforge.org/mailman/listinfo/jruby-extras-devel
