Sacha, I saw your stuff.
I had the idea from Marc that I would write a CMP bean, and you would provide a clever CMP implementation which would be of benefit not just to HttpSessions, but to anyone with similar requirements. Thus I figured I would write the bean and then work with you to swap the CMP implementation as a later optimisation. It looks like a misunderstanding. I will go back and reread your mails. It should be trivial to unplug my CMP bean and replace it with your store. No Problemo ! I'll check in what I've got first. Jules Sacha Labourey wrote: > Hello, > > > 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. > > Well, this does not really provide fail-over or load-balancing anyway. > > > 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. > > This is the solution that I have already implemented: please take a look at > my recent post on jboss-dev: a distributed store, an entity bean, and an > MBEAN for you. But you need to *always* call getSession and setSession: you > can't managed the session cache yourself in jetty. > > > 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 ! > > If all requests for the same session (sticky load-balancers in front-end) go > to the same node, we have an optimisation: the httpsession is cached in an > Entity bean (see my post on jboss-dev) > > > > > 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 ! > > I agree but existing applications would fail. > > > 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. > > OK, so let's make it an optional behaviour to be there as an optimisation. > > > I am working on the first solution at the moment. I shall have a > > good look at various > > well... solution 2-3 is already implemented! I've sent an e-mail to > jboss-dev recently (and to you) with the details of the implementation and > how jetty should use it. Have you seen/read it? > > 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
