Although your question is rather vage I'll try to give some hints on the same vage level.
If you are using a JDK > 1.2.* and < 1.4.1 you should do one of the following: - upgrade to 1.4.1 - use precompiled jsp's - use jikes to complie the pages - Just restart tomcat after all jsp have been compiled This is not a medium term solution, but may be approriate to isolate the resource leaks Make damn shure that you really release all db resources at the end of the methods. Several JDBC drivers are missbehaving if you don't explicitly close all statements, result sets, and connections. Make shure that the closing is executed no matter what happend in the method (Do all closing in a finally block off a try statement). Watch for Objects that are stored variables that are stored outside of methods. (Class/Instance/Session/Context/Application) Although I think you don't like the last answer (please read to the end) I have to provide it: Use a tool like OptimizeIt to find out, where the memory is consumed. The last time I looked, they had 30 days trial version, so you may not need to buy it. > -----Original Message----- > From: ilasno [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 19, 2002 8:29 PM > To: [EMAIL PROTECTED] > Subject: in search of more efficient design > > (including db-access module instances), so that within a > doGet or doPost > everything i need is created, and then i am assuming when the method > ends everything is garbage-collected? is it possible to have > that much > memory used just to hold 60 or 70 servlets ready for requests? I am > wondering if my design is flawed, or a bad idea altogether.. > > any help or guidance would be greatly appreciated. > > jesse > -- > i am deprogrammed > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
