tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Rossbach>
Subject Re: Why SavedRequest should be Serializable (or at least not stored in a Session note)
Date Mon, 18 Sep 2006 13:44:10 GMT
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.


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message