>From the Servlet 2.3 spec. SRV.7.7.2 Distributed Environments Within an application marked as distributable, all requests that are part of a session must handled by one virtual machine at a time. The container must be able to handle all objects placed into instances of the HttpSession class using the setAttribute or putValue methods appropriately. The following restrictions are imposed to meet these conditions: " The container must accept objects that implement the Serializable interface " The container may choose to support storage of other designated objects in the HttpSession, such as references to Enterprise JavaBean components and transactions. " Migration of sessions will be handled by container-specific facilities. The servlet container may throw an IllegalArgumentException if an object is placed into the session that is not Serializable or for which specific support has not been made available. The IllegalArgumentException must be thrown for objects where the container cannot support the mechanism necessary for migration of a session storing them. These restrictions mean that the Developer is ensured that there are no additional concurrency issues beyond those encountered in a non-distributed container. The Container Provider can ensure scalability and quality of service features like load-balancing and failover by having the ability to move a session object, and its contents, from any active node of the distributed system to a different node of the system. If distributed containers persist or migrate sessions to provide quality of service features, they are not restricted to using the native JVM Serialization mechanism for serializing HttpSessions and their attributes. Developers are not guaranteed that containers will call readObject and writeObject methods on session attributes if they implement them, but are guaranteed that the Serializable closure of their attributes will be preserved. Containers must notify any session attributes implementing the HttpSessionActivationListener during migration of a session. They must notify listeners of passivation prior to serialization of a session, and of activation after deserialization of a session. Application Developers writing distributed applications should be aware that since the container may run in more than one Java virtual machine, the developer cannot depend on static variables for storing an application state. They should store such states using an enterprise bean or a database.
So, the spec takes the simple route out. Ensuring that all requests forming part of a single session/conversation are routed to the same node avoids all the thorny issues which Marc is eager to overcome. I was going for a staggered solution. Firstly - Implement simply what the spec says, in a coarse grained way - i.e. passivate a session into distributed store on Jetty shutdown and re-activate it as-and-when needed in another Jetty instance. The only problem I forsee with this is garbage collection of orphanned (i.e. the Jetty instance that created them is gone, and the client that initiated their conversation has stopped talking) distributed sessions. This would work fine provided that Jetty shutdown was controlled. If not, the whole session is lost. Secondly - Like (1) - but more fine grained, and tunable. Distribute changes to the session according to some parameter e.g. every time an attribute is changed, at the end of every request, every minute etc... This approach could subsume all the fn-ality of the first, at it's most coarse grained, and also, at it's most fine-grained, ensure that if a node failed all conversational state up to that point would be preserved. But the cost would be higher in trips to the distributed store. Thirdly (the Holy Grail) Take (2) at it's most fine grained and relax the constraint on all requests for the same session going to the same node. This would allow any request to be routed to any cluster node, but at what cost ??? This seems to be Marc's dream ! Your point pokes a bit of a hole through (2) and (3). I think it would be fair enough to assume that, as the spec says, "Application Developers writing distributed applications should be aware that since the container may run in more than one Java virtual machine.....". Therefore they should do another setAttribute() after the setField(). Requiring this, whilst possibly being seen as a change of semantics by existing apps would allow us to be much more thrifty with our network ! Of course this doesn't exclude having a fourth implementation which attempts to stick to the old semantics and insists that we can't rely on this second setAttribute(). It just gives the developer the chance to speed up his app by giving us more help - without introducing a new API and without sacrificing any portability of his app. I am working on the first solution at the moment. I shall have a good look at various other app-server's approaches to these issues over the next few weeks. I think the most important thing to bear in mind is that we should implement a layered, pay-as-you-go solution, since one size will not fit all. Hope that helps, Jules Sacha Labourey wrote: > Julian, Can we get your feedback on this please? thank you! > > -----Message d'origine----- > De : Sacha Labourey [mailto:[EMAIL PROTECTED]] > Envoyé : jeudi, 3 janvier 2002 09:16 > À : [EMAIL PROTECTED] > Cc : Marc Fleury > Objet : RE: one more thing > > > BTW, Why clear the cache? Just overwrite the old data.... > > Yes, but we have two layers: the persistent store and the cache. > > In the persistent store, we simply overwrite the old data. > > In the cache, we remove the bean if it is in. > > > If you don't have a great load-balancer, then, so what, you will > > have lower > > performance. > > Yes, that's all. > > > But another thing, you have to update caches on all HTTPSession replicants > > on every invocation anyways, don't you? The CMP Entity will have no way of > > knowing if the Session attributes have changed or not. > > > MyAttribute my = (MyAttribute)session.getAttribute("my"); > > my.setField("foobar"); > > The HttpSession has no way of knowing if a my.setField was called > > since any > > object can be stuffed into session attributes. > > Yes, this is a problem. > > Two things. If the load balancer is smart enough, the CMP cache stores the > session in any cases, without propagating it to other nodes if no change > seems apparent. => the new session is kept but not propagated if no changes > seems to have taken place. > > Four solutions: > - we create a new class that subclass httpsession with a method such as > forceModified () > - we ask the developer to implement something like ".equals()" and we > compare each attribute with this. It is then the responsibility of the > developer to implement things correctly > - we force a cluster-write for every access (until now, it is not the case, > to avoid to replicate no changes but the last-access-time) > - we go the BEA way and the HttpSession is not clustered: it is another > object that is clustered. That is the developer responsbility to call this > clustered object correctly. > > We can mix some of these solutions and make it user-definable. > > What's your opinion? > > Thank you for this feedback and raising this issue, Bill. > > Cheers, > > Sacha _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
