Hi Alberto,
please start discussion only at one list!
I think we don't must support replication at SavedRequest objects.
Feel free to send us patch.
See Servlet Spec 7.2.2
==
Within an application marked as distributable, all requests that are
part of a session
must be handled by one Java Virtual Machine1 (“JVM”) at a time.
==
This means normally all requests form same session are handled
by same JVM. That also means, you must used "sticky session" at your
LB layer.
Only after a crash or admin migration the session become active on a
another node.
Changes of sessions are not thread save. Also transactional
synchronzation between different nodes
can be done effective.
Regards
Peter
Am 18.09.2006 um 12:52 schrieb Alberto Rodriguez Galdo:
Hi,
Servlet 2.4 specification states that
"Migration of sessions will be handled by container-specific
facilities." and
"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."
When Tomcat receives a request for a protected URL, the user is
redirected to the login page and a SavedRequest object is created
and stored as a note in the user session via setNote method of
org.apache.catalina.session.StandardSession (the note then gets
stored as an entry in a Hashtable inside the session).
As this object is not serializable, when any clustering
mechanism outisde tomcat (such as the ones that implement
application servers that embed tomcat to provide JSP/Servlet
processing) no easy mechanism can be provided to replicate the info
of a request to a protected URL before the authentication is
performed with a j_security_check POST (in a form-based
authentication environment).
Sticky sessions are a way of circunventing this problem but
doesn't provide full load-bancing and failover capabilities.
What are the chances of transforming
org.apache.catalina.authenticator.SavedRequest in a Serializable
Object and/or storing that object in the session to be easily
replicated so this problem is avoided and full replication schemes
would be implemented for SSO in clustered environments and so on?
--
Alberto Rodriguez Galdo
[EMAIL PROTECTED]
