#2 seems to be a much better way for various reasons - clustering support, session survival across processes etc. I suppose that the changes needed for this would be in the rails-integration layer (as opposed to the jruby layer). Is that right ?
Thanks Ashish Ola Bini wrote: > Hi guys, > > As you know, we have been seeing some strange intermittent errors when > running Rails-integration. (Jon's errors, for example) > Another one is: > assigning non-exception to $! > > The reason for all of these is fundamental flaw in the session > management. Since Ruby-objects are stored there, and can be fetched from > the session store by any runtime alive, that means sometimes there will > be a skew between the Ruby-objects runtime, and the runtime running the > request. This will lead to all sorts of mayhem, but right now the > problem was isKindOf not working, since the class A from runtime foo and > the class A from runtime bar isn't equal. > (Jon was right btw, this is EXACTLY the kind of classloader errors we > all love and see in Java systems. com.xyz.Foo cannot be converted to > com.xyz.Foo) > > So, how do we solve this? There are two solutions, and we need to do it > quite fast: > > 1. Implement session-affinity: one session always uses the same runtime. > This would be possible, but probably not efficient. > 2. Store marshalled versions of the Ruby-objects in the session store. > This would be closer to MRI semantics, and would also solve the runtime > problem. It would also mean that Rails-integration has serializable Java > sessions again, which is a requirement of most web containers. > > Any takers? > > Cheers > > _______________________________________________ Jruby-extras-devel mailing list [email protected] http://rubyforge.org/mailman/listinfo/jruby-extras-devel
