[jboss-jira] [JBoss JIRA] Closed: (JBAS-3545) HASessionState state transfer incorrect for replicated sessions

HASessionState state transfer incorrect for replicated sessions --------------------------------------------------------------- Key: JBAS-3545 URL: http://jira.jboss.com/jira/browse/JBAS-3545 Project: JBoss Application Server Issue Type: Bug Security Level: Public(Everyone can see) Components: Clustering Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-3.2.6 Final, JBossAS-4.0.2 Final, JBossAS-3.2.5 Final, JBossAS-4.0.1 SP1, JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1, JBossAS-3.2.8 Final, JBossAS-3.2.8.SP1, JBossAS-4.0.4.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-4.0.5.CR1, JBossAS-3.2.8.SP2 When HASessionStateImpl prepares state for a state transfer, it uses a timestamp check to see whether a bean is overaged before including it in the state. If the bean is overaged it removes it from its replicated cache. (Note that this is a separate and distinct process from the standard SFSB passivation and removal process.) This algorithm is broken for sessions that are not active on the node preparing the state transfer for two reasons: 1) The transient field used to store the modification timestamp (in PackagedSessionImpl) is initialized as part of its declaration: protected transient long lastModificationTimeInVM = System.currentTimeMillis (); This means the value will not be properly initialized when PackagedSessionImpl is deserialized, as is explained at http://forum.java.sun.com/thread.jspa?threadID=584981&messageID=3002515. 2) The lastModificationTimeInVM field is also not updated in the update() method, which is the method that gets called when state updates are replicated from another node. The effect of this is that when a state transfer is prepared, all remote beans will be removed from the replicated cache of the preparing node. At a minimum this means the bean won't be included in the state transfer; it may have other insidious effects on the preparing node as well. Fix is to initialize the transient field in the constructor and readObject() and to update it in the update() method.