Hello Hannah! Not an expert, but all the measures (except measure 6) are targeted at reducing the total number of objects in memory.
Yes, transferring objects from session to request scope is good for the following reason: imagine a user presses a link once in a minute. If the bean is in the session it will remain in memory until the user stops interacting with the server and his session times out. If the bean is in the request scope then it will only be created once in a minute, remain as long as the request is processed (that's no more then a second or two, I hope, it could be even less) and then be gc-d. See the difference: present all time or only 2 seconds of every 60? The number of concurrent objects reduces dramatically! Judge every measure in your list against the following criterion: does it reduce the number of objects in the memory at any given moment? How? Why? And thanks for a good job of putting all these advices together! :-) HL> The Jrun 3.02/IIS 4.0/NT 4.0/JVM 1.3.0_02 servers HL> all seem to run out of memory(JVM configured at HL> min=max= 512MB) after about 12 hours: HL> java.lang.OutOfMemoryError HL> <<no stack trace available>> HL> A search of the archives suggested several ways to HL> save memory: HL> 1) closing all DB objects like result set, prepared HL> statements, returning all connections to pool HL> 2) setting session time out to a shorter interval: HL> currently configued as 20 minutes, change to 15 HL> session.setMaxInactiveInterval(com.adv.jsp.JSPUtil.SESSION_TIMEOUT_SECS); HL> 3) add a session.invalidate() to signout process HL> 4) use session.removeAttrbute() to remove objects HL> from session when they are no longer needed HL> 5) release remaining references to beans in session: HL> not using HttpSessionBindingListener but are there HL> other ways an object in session can still have active HL> references which would keep it from being garbage HL> collected? HL> 6) use Jprobe or OptimizeIt HL> downloading the trial but no experience with the HL> product yet HL> and now considering this: HL> 7) change session scope objects to request scope HL> whereever possible HL> Would changing scope of a java bean from HL> session to request save memory even if it means HL> creating and garbage collecting the object more HL> frequently? What are the trade offs of calling the HL> object's constructor more frequently as a request HL> scope object but making the object available HL> immediately for garbage collection as opposed to HL> making it session scope and delaying the garbage HL> collection? HL> For example in the index.jsp: HL> <jsp:useBean id="product" HL> class="com.adv.beans.ProductBean" scope="session" /> HL> only creates the ProductBean once per session HL> could be changed to HL> <jsp:useBean id="product" HL> class="com.adv.beans.ProductBean" scope="request" /> HL> which would mean changing session references to HL> request.getAttribute() throughout the JSP - Anton [EMAIL PROTECTED] [EMAIL PROTECTED] =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
