I am looking to protect the session by creating a backup session. Then if the app has been inactive for the standard 30mins then a check could be made to see if the session still exists. If it does not exist, an option is given to restore the session from the backupSession. All I need to know is if the main session (Call it 'sess') times-out at 30mins and backupsSession is set to: backupSession.setMaxInactiveInterval(60*60*60*4); // Set to 4 hours When the timeout occurs will backupSession still exist or is backupSession riding on the back of sess and will timeout at the 30minute mark? Thank you in advance, Gary
I don't think this would work - the servlet engine only manages one session at a time per user. You could establish a separate persistance method for an object with your custom cookies for an ID but it would not be a session. If you store a custom object in a session you can provide for being notified when the session is about to delete the object and store it elsewhere - for instance serialize to disk. Alternately just make the standard session timeout longer. Bill
Originally posted by Gary Busby: I am looking to protect the session by creating a backup session. Then if the app has been inactive for the standard 30mins then a check could be made to see if the session still exists.
Gary, This is a strange thing to be doing. It might help if you explain the purpose of your backup session. Meanwhile, I can tell you about a related way of "protecting" sessions. The purpose is to allow multiple (clustered) web servers to act as real-time backups for each other: If the server that has been serving a given client's session goes down, for example, you want another one of the web servers to handle incoming requests which will be automatically routed to a remaining server. Thats the purpose. One is "session replication". In this case, if you have only two web servers, then each session on one is transmitted in real time for every method request to the other in memory. Cool, huh? But if you have numerous web servers, they can use disk (to avoid memory over consumption). This does not even tap the power of J2EE. Another solution involves J2EE. I'll elaborate if you're interested. John
Juan Rolando Prieur-Reza, M.S., LSSBB, SCEA, SCBCD, SCWCD, SCJP/1.6, IBM OOAD, SCSA