Why SavedRequest should be Serializable (or at least not stored in a Session note)

[Alberto Rodriguez Galdo <ar...@gmail.com>]

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

Re: Why SavedRequest should be Serializable (or at least not stored in a Session note)

[Alberto Rodriguez Galdo <ar...@gmail.com>]

>
> 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.
> ==
>


That is quite a good reason.

Regards,

-- 
Alberto Rodriguez Galdo
argaldo at gmail.com

Re: Why SavedRequest should be Serializable (or at least not stored in a Session note)

[Peter Rossbach <pr...@objektpark.de>]

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