-
1. Re: Session replication - expiration
brian.stansberry May 23, 2008 12:05 PM (in response to gjwilk01)What AS version?
In 4.0.5 I added a check where if 80% of the session's maxInactiveInterval has passed since last replication, even a read request will cause the session to replicated.
There was actually a bug in 4.0.5 that that would cause it to replicate much more frequently than that (http://jira.jboss.com/jira/browse/JBAS-4428). That was fixed in 4.2.1.
I now think the standard 80% is too high. You can control that 80% value by adding a Tomcat context.xml file to your war's WEB-INF dir with a Manager element:Context cookies="true" crossContext="true"> <Manager pathname="" maxUnreplicatedFactor="10"/> <InstanceListener>org.jboss.web.tomcat.security.RunAsListener</InstanceListener> </Context>
You can also use a maxUnreplicatedInterval attribute instead of maxUnreplicatedFactor to specify the maximum unreplicated time in ms.
In AS 5 the same will exist, but I'll also replicate the timestamp of the session if it hasn't been replicated w/in 60 seconds. In AS 5 the timestamp can be independently replicated, so aggressively replicating is less expensive than it is in AS 4.
Please note that in all these cases, it is a web request that triggers the replication; i.e. there isn't a background thread or something that does it. -
2. Re: Session replication - expiration
gjwilk01 May 23, 2008 12:29 PM (in response to gjwilk01)Hi, Brian.
We are running AS 4.2.2 GA.
So, if I understand this correctly, regardless of how the replication trigger is configured once the maxInactiveInterval has passed since the last replication, first subsequent read request will trigger replication. This means, that at a very least we should read some value from session on each request, correct?
Thanks,
~george -
3. Re: Session replication - expiration
brian.stansberry May 23, 2008 1:17 PM (in response to gjwilk01)You don't need to read an attribute, just need to be sure HttpServletRequest.getSession() is invoked. You should verify, but I think it almost always is without any effort on your part; e.g. by the Tomcat authentication logic if you use container managed security or by populating the standard 'session' variable if you use a jsp.