tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Rossbach ...@objektpark.de>
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.

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
> argaldo@gmail.com


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