I'm not quite sure where our misunderstanding is coming from. I agree
with you that storing a connection in the connection pool for each
individual user is a Bad Thing. That's not what ObjectPool does. I
then mentioned that it would be useful for guest logins. Say you had a
dozen or so different reports that contained non-sensitive data. You
also use database records to compose dynamic HTML forms so that users
can choose values from drop down lists as opposed to text field entry.
Keeping a pool of 5 (just for the sake of example) connections (logged
in as guest) keeps you from having to instantiate a connection for each
user request/user session. You keep all the security precautions you
need (i.e., read only, just specific columns in specific tables,
whatever), but if these nonclassified requests make up a nontirvial
portion of your database I/O, you can get a speed win with
ConnectionPool (my own non-scientific tests showed a .25 - .5 sec time
to instantiate a database connection).
Adding "su" capabilities to the equation certainly makes it much more
broadly applicable as a solution, but even without it, the pattern does
address an issue...
--
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
