What connection pooling in Oracle8i are you talking about?
They have connection muxing, but not pooling.
The have multiple session per-connection (but that is not pooling).
I'd be interested to hear about the pooling they have.
Thor HW
----- Original Message -----
From: Andres Aguiar <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 11, 1999 1:54 AM
Subject: Re: Further on Session problems with Java Servlet Programming
Book...
> 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
>
___________________________________________________________________________
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
