Mark Hayes wrote:
> I'm pretty sure any memory overhead per client session will dramatically
> effect scalability. That's why EJB SessionBeans have the ability to
> "passivate themselves" to free up memory during heavy load conditions.
That's what I mean though, if you have a ton of memory - say 1GB - which
isn't that much these days for a high powered server, why would that matter?
I think java would bomb out on the number of working threads problem before
you'd have a problem with memory being sucked up by session data. I mean if
you have a server with 64MB of ram and it starts swapping memory to disk
then you're in trouble but like I said if you have 1 or 2GB of memory,
that's probably not going to happen before you have too many threads
crashing your JVM.
> One deficiency of servlet sessions is that there is no notification (callback)
> when the session times out. If there was, this notification could be used
> to store the session data in the database, for example. That way, the
> session timeout interval could be made small to increase scalability.
Have you looked at HttpBindingListener interface? This does exactly what
you are talking about if you implement your session data classes from it.
If you implement valueUnbound(HttpSessionBindingEvent event) your class
will be notified when the session times out and you can take any appropriate
action necessary.
> As it
> is, to be highly scalable we're forced into not using session data for
> multi-page form situations--instead we need to write this information to the
> database on every form submission.
What did you use to benchmark the performance/scalability of these two
methods of maintaining state. My feeling is that sessions were designed and
implemented so that you don't have to maintain state in a database unless
you're planning on keeping user data around for a really long time (i.e.
longer than a user "session"). I'm not understanding how writing every
GET/POST of form data to a database is more scalable than just using
sessions (unless like I said you're keeping session data around for multiple
visits). Writing to a database is something I consider a relatively high
cost operation even when using connection pools, etc.
Mike
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
