tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Duan, Nick" <>
Subject RE: JDBC Session Persistence in a cluster problem/question
Date Tue, 10 Jan 2006 19:45:14 GMT
Could this be the reason that the failover can't succeed?

Tomcat HOWTO on session replication: Make sure your web.xml has the
<distributable/> element or set at your <Context distributable="true" />


-----Original Message-----
From: Paul Smith [] 
Sent: Tuesday, January 10, 2006 1:45 AM
Subject: JDBC Session Persistence in a cluster problem/question

	Subject: 	JDBC Session persistence in a cluster
	Date: 	10 January 2006 5:42:51 PM

[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/" >
className="org.apache.catalina.session.PersistentManager" >
                         sessionTable ="tomcat_sessions"
                         sessionAppCol = "app_name"
                         sessionDataCol = "session_data"

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  

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.


Paul Smith

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message