Additionally, since GC isn't predictable, you may run out of pooled
objects real fast.
Consider a DB app with a connection pool of 24 connections, and 1GB
of free heap.
It processes ten requests per second and each request uses up
10MB of memory. This means that it will take 100 requests to
use up the memory, but only 24 to use up the connections, by
which time the JVM won't GC since you have 760MB of heap left
to much through.
Sure, you can run GC like a nutter in the background, but this
seems a bit severe.
I think we came up with the following last time:
Two choices:
1. manager.release() - as it is now.
2. Require that each service interface that can have a pooled
implementation (SAXTransformer, Connection, etc.) has one
method (endDocument(), close(), etc.) that, after it is called
the component can return to the pool safely.
My own thought is that we shouldn't rely on GC to do anything
except give us the illusion of an infinite heap. It is too
unpredictable.
/LS
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Leo Simons
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
