One thing that concerns me about the JSP model of storing state and beans on
a session object is scalability. If you don't know what you're doing, the
bean
could end up causing big memory leaks. Secondly, what if the bean keeps
lots of references around to other objects? You won't get that memory back
until the session expires. When the session state gets swapped out, it might
end up serializing a large amount of objects to disk too?
I wonder if any JSP engines have been written to minimize heap thrashing?
JSP beans should, IMHO, store as little state as possible, and be primarily
oriented to stateless programming, or presentation of EJB related data.
Some metrics:
I've noticed that on average, a no-op JSP page in JRun2.3 consumes 30k of
heap, and on JWS, it consumes 40k of heap. Running a simple DB querying
servlet will eat up like 100k-400k of heap per request.
At 100 concurrent requests, you're chewing up 10-40mb of heap for
a very simple operation. Now, if your garbage collector is good
(JDK1.2 on Solaris), it's fine. But it won't help if some bean is holding on
to lots of references.
I have a very large scale project I am working on now, and I use Soft and
Weak references in JDK1.2 to put state on the session. If the reference
gets nulled out, I requery for the cached data. But I worry if there is a
permformance hit using them, that is, does Soft/Weak references slow GC down
because they need special treatment (like checking/updating Reference
queues?)
I like the metrics you guys ran, but could you try it again on Solaris x86
or Solaris SPARC? It is my experience that Solaris threads scale alot
better, and the Solaris Production Java VM is much better than the Windows
NT one.
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
