Dan,
> Cookies get a
lot of bad press. But, cookies (or complex URL encoding) are the
fall-back
> when session beans are not going to
be used.
Many JSP developers will shun session
> beans because the app might get deployed on clustered servers (reverse proxied).
> Each POST might then be dispatched to a different JVM. Session beans were not shared
> correctly among clustered JVMs until Servlet 2.3. (Correct me if I am wrong.)
> Nobody is there yet in the commercial offerings.
> beans because the app might get deployed on clustered servers (reverse proxied).
> Each POST might then be dispatched to a different JVM. Session beans were not shared
> correctly among clustered JVMs until Servlet 2.3. (Correct me if I am wrong.)
> Nobody is there yet in the commercial offerings.
iPlanet does, and I'm sure other vendors do
also.
I'm a little lost here about the DHTML & JS stuff,
but you might have a misunderstanding about cookies.
but you might have a misunderstanding about cookies.
You can turn cookies
off in the browser, but the Appserver should
implement them via the
jsessionid. Cookies are fine
for a cluster environment.
The servlets must be marked as sticky, meaning
each subsequent request will
return to the correct
JVM. Of course, this might depend
on the Appserver being
used, and how your
cluster is configured.
At my present job, we have 3 machines running 10 JVM’s, a total of 30 JVM’s
in the cluster.
If your not using session beans, are you using HttpSession?
At my present job, we have 3 machines running 10 JVM’s, a total of 30 JVM’s
in the cluster.
If your not using session beans, are you using HttpSession?
-
malcolm
