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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
