JDBC Session Persistence in a cluster problem/question

[Paul Smith]

        From:     [EMAIL PROTECTED]
        Subject:        JDBC Session persistence in a cluster problem/question
        Date:   10 January 2006 5:42:51 PM
        To:       [EMAIL PROTECTED]
[For context, Tomcat 5.5.12]

Hello all,

I'm having a bit of trouble understanding exactly what the  
capabilities are of the whole PersistenceManager and how it saves  
session data.  here's what I we have configured in server.xml:

       <Host name="localhost" appBase="foo" >
                <Context path="/" docBase="${catalina.home}/app/mel/" >
                 <Manager  
className="org.apache.catalina.session.PersistentManager" >
                        <Store  
className="org.apache.catalina.session.JDBCStore"
                         
connectionURL="jdbc:inetdae7:tower.aconex.com? 
database=paul&amp;user=sql&amp;password=sql"
                        driverName="com.inet.tds.TdsDriver"
                        sessionIdCol="session_id"
                        sessionValidCol="valid_session"
                        sessionMaxInactiveCol="max_inactive"
                        sessionLastAccessedCol="last_access"
                        sessionTable ="tomcat_sessions"
                        sessionAppCol = "app_name"
                        sessionDataCol = "session_data"
                        />
                 </Manager>
        </Context>
        </Host>

Sessions are persisting, as we can see the new rows being added to  
the DB.  Fine, great.

However in our test cluster environment we have noticed that session  
variables (strings, Integers) are being "lost" during the failover to  
the other node in the cluster.  From looking at the Javadoc of the  
PersistentManager and other related info on the net, I can't see  
anywhere where it indicates that the Session is persisted to the DB  
when the session is updated/modified/addedto.  It seems to only have  
settings that set how long to wait before saving to the persistence  
store.

1). Am I correct in my understanding so far?
2) . If so, is this design because of the likely performance impact  
of all these session changes, and the somewhat unlikely case of the  
server going down in the first place.
3). do I have any options here?  We really do need a pretty seamless  
failover with session information being kept in sync as it failsover  
to the other node in the cluster.

cheers,

Paul Smith