RE: long sessions
| I don't believe Orion (or other J2EE containers) distribute | changes to the ServletContext object to other VM/Cluster | members? According to Servlet Spec the ServletContext exists per VM only - and it states that this is even true in a distributed environment. For global data you should use EJB or DB instead. So no automatic sharing there. | To address these requirements, you'd need to persist the user's | access date state on a shared resource in your cluster. | Serialized UserState objects on a shared file system, or a DB table. Well - I am still not confident which works best. Anyone else any experiences in implementing a clustered global application context which allows sharing? In my current issue DB and file system aren't an option - so we currently run an experiment with http servlets listing to JMS (and write information in the app context and synch them via JMS). Depending on the app server you run into issues because of non clusterable JMS Server ... Recommendations? Jens
Re: long sessions
hi people I posted the original thread on this just to clarify, there is just one app server, no clusters. the site works fine, no problems with sessions at all I was just wondering what would happen if the server had to hold on to these session objects for a much much longer period of time cheers Jens Schumann wrote: | I don't believe Orion (or other J2EE containers) distribute | changes to the ServletContext object to other VM/Cluster | members? According to Servlet Spec the ServletContext exists per VM only - and it states that this is even true in a distributed environment. For global data you should use EJB or DB instead. So no automatic sharing there. | To address these requirements, you'd need to persist the user's | access date state on a shared resource in your cluster. | Serialized UserState objects on a shared file system, or a DB table. Well - I am still not confident which works best. Anyone else any experiences in implementing a clustered global application context which allows sharing? In my current issue DB and file system aren't an option - so we currently run an experiment with http servlets listing to JMS (and write information in the app context and synch them via JMS). Depending on the app server you run into issues because of non clusterable JMS Server ... Recommendations? Jens
RE: long sessions
The only real disadvantage is that you are making your memory footprint larger, but that can cause other sorts of situations (OutOfMemoryExceptions, making garbage collection take longer and potentially eat up more CPU, etc). Of course you could always just increase the memory allocated to the JVM. If the user object is the only thing in the session and its relatively light-weight, its probably not a big deal. If the user object is mid sized or larger, or you are storing other things in the session expect to see a noticable memory increase. -Original Message- From: Tim Courtney [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 29, 2002 7:17 PM To: Orion-Interest Subject: long sessions I have kind of a general app server question: I have a servlet that puts a user object into session - HttpSession session = req.getSession(true); session.setAttribute(user, user); - We use this object to check if a visitor has logged into the web site or not My boss has asked me to increase the timeout of this session to 8 hours !!! Apart from the obvious security issue, I was wondering about the load on the server. Is holding too many session at once a common cause of server failure ? I can't really give details about the number of users, but assume there will be a few hundred at any one time. The hardware specs of the app server are about mid range. thanks
Re: long sessions
We use this object to check if a visitor has logged into the web site or not
Using HttpSession for checking definitatively whether that user has
logged in or not won't
work.
The HttpSession will still be associated with that user's browser if and
only if they
use the same browser. If they use Netscape VS IE, different cookie and
thus different
HttpSession. Stop start the same browser, different cookie again.
Use a HashMap/HashTable in the ServletContext object, keyed on userID
instead. Create an instance of UserAccess object and add to the the
HashMap in the
ServletContext.
class UserAccess {
Date lastAccessDate;
String userID;
...
}
This will be absolutely a minimal impact on memory foot print and work.
Good luck,
curt
long sessions
I have kind of a general app server question: I have a servlet that puts a user object into session - HttpSession session = req.getSession(true); session.setAttribute(user, user); - We use this object to check if a visitor has logged into the web site or not My boss has asked me to increase the timeout of this session to 8 hours !!! Apart from the obvious security issue, I was wondering about the load on the server. Is holding too many session at once a common cause of server failure ? I can't really give details about the number of users, but assume there will be a few hundred at any one time. The hardware specs of the app server are about mid range. thanks
