I every user connects with a different user/password to the database, no
connection pool can't do anything to help you... But if you have the users
grouped (ie Marketing users, etc), and everyone in each group connects to
the database with the same user/password, you can pool connections for each
group. You can't assign a 'marketing connection' to a 'superuser
connection', but you can share them between groups.
Anyway, I think the connection pooling built inside Oracle8i does share
connections from different users, but as it's done at the database level,
they can separate the 'real connection' from the 'user context', and have
more 'user contexts' that 'real connections'.
> -----Original Message-----
> From: A mailing list for discussion about Sun Microsystem's
> Java Servlet
> API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of
> Matthew G. Kelley
> Sent: Wednesday, August 11, 1999 3:07 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Further on Session problems with Java Servlet Programming
> Book...
>
>
> On Tue, 10 Aug 1999 18:44:13 -0500, Bob Withers
> <[EMAIL PROTECTED]> wrote:
>
> >We do something similar but do use a connection pool. The pool just
> >accepts userid/password as parameters to getConnection and returns a
> >connection for that userid. A background thread shuts down
> connections
> >that exceed some maximum idle time.
>
> I had thought to do this as well. The problem I couldn't
> figure out how to get
> around was how to validate authorization in the case where a
> connection is
> reused from the pool. If a _new_ connection is established,
> the provided user
> ID and password are checked as part of the establishment.
> How do I make sure
> that a valid user ID with a bogus password have not been
> provided if I don't
> establish a connection? If I tie the establishment of the
> connection to the
> establishment of the session, then reusing that connection
> for the lifetime of
> that session seems ok, but what about across sessions?
>
> -Matt
>
> ______________________________________________________________
> _____________
> 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
___________________________________________________________________________
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
