Cezar said:
[snip, snip]
> It is simpler in this case to keep one opened database connection
> (user specific) within HttpSession:
[code on inserting an object into a session snipped]
While this is true, it doesn't really address the issue. What any
object pool tries to do is keep the instantiating of objects to a
minimum by pre-creating them and storing them in a "cache". Client
requests are then fufilled by the cache, as opposed to having the VM
instantiate the object when it is requested. This cuts down on
turn-around time. The session is going to be used to store the
connection, the question that ObjectPool tries to solve is "Where will
the connection come from?"
It is far from useless to have a connection pool. Many times, reports
can be generated that have no security value, and thus can use a "guest"
login. Keeping the pool prevents you from having to instantiate a guest
connection for every request by making them up ahead of time, and
returning them to the pool rather than gc'ing them when they are no
longer in use. DB connections are not the only thing that can be
pooled, and as we stated above there are issues with pooling them, but
it is a legitimate way of solving certain, pervasive issues...
--
Within C++ is a smaller, cleaner language
struggling to get out.
It's called Java.
Thomas Moore
[EMAIL PROTECTED] Home Account
Software.Engineer [EMAIL PROTECTED]
phone://732.462.1880:268 NJ Patterns Group Home Page
employer://Celwave, RF http://members.home.net/twmoore/cjpg
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
