Hello Bill,
> You should be able to use this for SFSB as well. That way you
> can reuse the
> SFSB timeout stuff that's in SFSBInstanceCache.
Yes, I think that we could put the SFSB thing with sub-partitions in the
todo-list with lower priority and make SFSB à la HTTPSession (i.e. without
SubPartitions). This would make the invocation fixing easier for you.
> > Caching
> > =======
> > Thanks to the distributed cache mechanism, if you use a front-end
> > load-balancers that support sticky sessions, all requests of the same
> > session will be targeted at the same node. Consequently, the
> > jmxservice.getSession() call will a return a session that is
> > still in cache
> > and the overhead will be very small. This is good news. The servlet
> > container, should not try to handle caching of session itself for a good
> > reason: it can't. It doesn't have sufficient cluster knowledge
> to be sure
> > that he owns the last version of the session.
> >
>
> Even if you don't use a smart load-balancer, your calls should be
> collocated
> anyways as long as you're in the same Partition, correct?
Well, imagine that you have 3 jetty-jboss instances running in front-end. To
have load-balancing/fail-over, you need some kind of hard/soft
load-balancers in front of the cluster. If this LB supports sticky-session,
that's ok. But, if the LB only load-balances calls as they arrive (dummy
round-robin), requests belonging to the same session may be sent to
different nodes at each request. Consequently, the cache on each node won't
be very usefull: when a request for session A arrives on node 2, node 1 and
3 caches must be cleared.
Cheers,
Sacha
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
