> From: Mike Engelhart [mailto:[EMAIL PROTECTED]]
>
> > 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 should have explained that our situation involves the use of NAS (Netscape
Application Server) using their failover mirroring and non-sticky load
balancing. The bottom line with that stuff is, not only can session data
use a lot of memory under heavy load, but the session data also needs to be
replicated between servers for failover and load balancing. This means that
session data adds up to a significant performance factor. For a
single-server system, it would not be as significant and in that case adding
as much memory (and setting the timeout to a longish interval) as possible
may be the best strategy.
> > 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.
Thanks, that is really helpful information. In which servlet implementation
have you seen this happen? I naively assumed that the "unbound"
notification would only take place when the value was explicitly set to null
by the application, and I didn't test it :-(. If this happens on session
timeout as well, that's perfect -- I can then write the session data to the
database only when the session times out.
> 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.
I admit we have not done much benchmarking, and some of this is based on the
recommendations of the Netscape/Sun folks for using NAS in our particular
situation.
I agree that database access is costly, and we only plan to do it when
really necessary. However, as I tried to describe above, we believe we have
to avoid using session data whenever possible and the database gives us the
reliability we're after. We won't need to save every form post, but for a
multi-page form where the "business object" is not committed until the last
page, we think we will need to save the data for the intermediate pages in
the database. While we won't save this intermediate data forever, we do
want to handle the case where a user goes for a long lunch as well as where
they go home at night and come back the next morning. So, we may keep the
data around for a few days. Yes, this means a "cleanup" task for the
session database data is needed also...
Now, a completely different use of the session is for caching. Using the
session to cache database information or data which was costly to compute is
definitely useful. But in this case we can set the timeout as low as
needed, and then refetch or recompute the data after a session timeout. In
other words, we can tune this for best performance without changing the
behavior for the user.
Thanks for your comments, they are very helpful.
mark
===========================================================================
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
