]
Brian Stansberry commented on JBAS-5735:
----------------------------------------
Fixed in Branch_4_2.
Session not reliably bound to SessionReplicationContext if
SecurityAssocationValve not present
----------------------------------------------------------------------------------------------
Key: JBAS-5735
URL:
http://jira.jboss.com/jira/browse/JBAS-5735
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Clustering, Web (Tomcat) service
Affects Versions: JBossAS-5.0.0.CR1, JBossAS-4.2.2.GA
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Priority: Minor
Fix For: JBossAS-4.2.3.GA, JBossAS-5.0.0.CR2
The call in JBossCacheManager.findSession(String id) to
SessionReplicationContext.bindSession(...) only binds the session if ClusteredSessionValve
has first called SessionReplicationContext.enterWebapp() to establish the context. The
problem is, if any code calls Request.getSession(...) before ClusteredSessionValve is
invoked, the session will be cached in the request, not bound to the context, and
subsequent calls to Request.getSession(...) will use the cached session and never call
JBossCacheManager.findSession(...). Result is the session will never be bound to the
context and won't be replicated.
BatchReplicationClusteredSessionValve calls Request.getSession(...) before
ClusteredSessionValve is invoked. SecurityAssocationValve happens to save us, by
providentially calling Manager.findSession(...) after the request has passed through
ClusteredSessionValve. But that's just good luck; we need to make sure the session is
properly bound to the context.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: