And bad. Every time I restart, Tomcat loses the state information for established login sessions. Customer don't like that.
That (with a high probability) is because some objects they store in sessions are not Serializable. IOW, they violate the Servlet Specification.
I'm just curious: is this actually a violation of the servlet spec? The API seems to indicate that you can put anything in the session that you want. I don't think it has to be Serializable... thought I was wrong before, once ;)
Tried that. Capped it at 35 and the webserver stopped servicing any DB request as soon as the pool reached 35. This is why I believe the pool management is faulty and/or something is hogging all the connections.
I share your belief. Let's try to prove it. Raise it to some other figure, and see if the same happens again. Ask them how big should the figure be.
In fact, cap it at 10 and watch the app dring to a halt before it even gets going. This is a pretty compelling example. If the pool is drying up, they're definately screwing up.
Oracle 9i takes 16M per connections. So Oracle claims. I've tested it as high as 20M. I generally use 18M as a guideline
I've heard (not a DBA, though) that Oracle 9i has a mode where it does not spawn a process per connection, but uses threads instead (?) and in that mode it uses far less resources. This way, we have some modest Oracle servers hjandling up to 300 simultaneous (mostly idle) connections.
It depends on the size of your rollback segments and the number of transactions you are doing. If you do big transactions, each DB connection (thread *or* process) wioll need a big chunk of memory. I wouldn't kill yourself trying to figure out how to reduce this process size. Fix the real problem, which is poor connection management.
I'll mention DBCP and see what happens
DBCP has a nice "removeAbandoned" feature.
Otherwise, you can use this code (tweak it to your needs) to track where connections are opened and closed from:
(code not tested at all)
// open method signature
// code that opens the connection (and stores it in "conn" variable)
try {
throw new Exception("Pool Debugger says: Connection <" + conn + "> opened:");
} catch (Exception e) {
e.printStackTrace();
}
I've seen code like this before. Many people think you can't get a stack trace unless you throw an exception. Not so. All you have to do is instantiate it, and you get the stack trace. So, the following will produce identical results, without the nasty try/throw/catch:
new Exception("Pool debugged says: ...").printStackTrace();
I would recommend explicitly printing out the hashCode of the Connection object itself, just in case the connection doesn't include any identifying information in it's .toString method.
Then you can... #!/bin/sh # Filter pool debugger statements.
This is a pretty good idea for some basic debugging. You should only have to demonstrate to your devs that you can deadlock their server by capping the connection pool. After that, it's their problem, right? :)
-chris
signature.asc
Description: OpenPGP digital signature
