Hi,
I said there is no sense to have a connection pool open a
connection for each possible JDBC userid (just for the cache's sake)
than to open the connection only when the user actually
accesses its session (and reuse that session-bound connection as
long the session lives)
Assuming I'm wrong, and such a pool is usefull, how do you get user's
password before he logs in the session? The main issue in discussion was
not to let such a pool keep valid passwords.
Not counting an ideal JDBC driver with "su" capabilities.. bet if there are
two JDBC drivers with such behaviour they implement it using different
proprietary calls().
Cezar
On Thu, 25 Mar 1999, Thomas Moore wrote:
> 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
>
Cezar Totth email: [EMAIL PROTECTED]
Fax: (401) 220 33 95
Genesys Software Romania Phone: (401) 638 49 44
Stefan Furtuna 169, sect.6
cod 77171, Bucharest
Romania
___________________________________________________________________________
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
