tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Filip Hanik" <m...@filip.net>
Subject RE: getSession() returns a different StandardSessionFacade object every time it is called
Date Sun, 02 Mar 2003 00:38:18 GMT
why don't you just synchronize on an object stored in your session, bada bim
bada bom :)

Filip

~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
www.filip.net

>-----Original Message-----
>From: Paulsen, Jay [mailto:jay-paulsen@uiowa.edu]
>Sent: Saturday, March 01, 2003 11:04 AM
>To: 'tomcat-dev@jakarta.apache.org'
>Subject: getSession() returns a different StandardSessionFacade object
>every time it is called
>
>
>
>
>Environment:
>Tomcat 4.1.12
>Apache 2.0.43
>Warp Connector
>Struts 1.1b2
>
>Calling getSession() on the request object (which in this environment is an
>instance of HttpRequestFacade which wraps a WarpRequest) creates
>and returns
>a new StandardSessionFacade object that actually wraps another
>StandardSessionFacade object which wraps the StandardSession object.  This
>means that every call to request.getSession() returns a different
>StandardSessionFacade object making it impossible to synchronize on the
>session object.
>
>It looks like that the code in HttpRequestFacade.getSession() that
>wraps the
>session in another StandardSessionFacade object is unneeded, possibly.  The
>call it makes to StandardSession.getSession() already returns a session
>object wrapped in a facade object.
>
>Am I completely missing something here?  If this is the intended behavior,
>is there another alternative to synchronizing on the session object? The
>Action.isTokenValid() method in Struts has a synchronized block on the
>session object.  It looks like that this code would not work on Tomcat
>because of this scenario.
>
>I also quickly looked at Tomcat 4.1.18 and Struts 1.1rc1 and the
>code in the
>above mentioned objects looks the same.  The CoyoteRequestFacade class used
>by the Coyote Connector does the same thing too.
>
>Any insight on this is greatly appreciated.
>
>Regards
>-Jay
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message