Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: connection pooling from an application server to oracle

Re: connection pooling from an application server to oracle

From: Mladen Gogala <mgogala_at_adelphia.net>
Date: Mon, 15 Dec 2003 21:04:27 -0800
Message-ID: <F001.005D9FB3.20031215210427@fatcity.com>


I didn't reply to Vadim because I'm not a developer and I have no idea how appservers work. You say that as of 9i application servers can use OCCI multiplexing. Isn't that dependendent on a particular app server? I was talking about iPlanet 6.5 because that is the last version that I have some experience (however painful) with. I was under the impression that pooling is implemented differently in WebSphere (IBM) or WebLogic (BEA). This is a question, not a statement. When it comes to beasts like application servers, my knowledge is extremely shaky.

On 2003.12.15 19:54, David Hau wrote:
> From 9i on, application servers can actually make use of the connection
> pooling and session pooling features within OCI instead of implementing
> their own.
>
> An interesting concept is how the 9i OCI API separates the notion of
> session pooling from connection pooling. You can have multiple session
> pools and multiple connection pools at the same time in an environment.
> A session pool is a pool of user handles. A connection pool is a pool
> of server handles. A session pool on top of a single physical
> connection means you can multiplex multiple sessions on a single
> connection by switching in and out of different transaction contexts.
> What's neater is having a session pool on top of a connection pool.
> You can multiplex say 10 sessions on top of 5 physical connections.
> Each time you obtain a session, you specify which session pool and which
> connection pool you want to use.
>
> Also, I believe that the client can store a pointer to a transaction
> context on the server side. This means you don't need to tie a physical
> connection to a transaction. You can use a different physical
> connection for each step of a transaction simply by passing it the
> pointer to the transaction context corresponding to that transaction.
>
> I think the JDBC driver has connection pooling also, but not session
> pooling. OCCI might have both. But I haven't checked.
>
> BTW, connection pooling and session pooling are new features in the 9i
> OCI. The 8i OCI does not have these features.
>
> Regards,
> Dave
>
>
>
> vadim.gorbounov_at_sigma-systems.com wrote:
>
> > Mladen,
> > Probably, something is very wrong with application design.
> >
> >
> >>With iPlanet, it looks like this:
> >>Application invokes bean, pumpkin or servlet which has something to do
> >>with oracle. The app server pooling mechanism will allocate one of the
> >>already established dedicated server connections, which will perform the
> >>work. When the same user executes another vegetable (EJB or servlet), he
> >>or she may do so within a different dedicated server connection. We have a
> >>situation in which a single user utilizes several dedicated server
> >
> > connections
> >
> >>within a single logical screen.
> >
> >
> > Usually application server is smart enough (we use Weblogic) to reuse same
> > physical connection if any number of calls comes from any different places
> > once all the calls are a single transaction.
> > I can imagin single call to allocate more than one connection if more than
> > one transaction contexts required for this call (although, smartest app
> > servers and the best databases can optimize even this transaction can be
> > suspended and then resumed after another transaction commits), but it must
> > be some very special need - it is not common what I'm saying.
> > Single logical screen probably cannot use connections at all: screen means
> > control is on users side means transaction should not be opened means no
> > connection assigned .
> > So, it's probably not an architecture's fault, it's design issue.
> >
> > Regards
> >
> > Vadim
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: David Hau
> INET: davehau123_at_netscape.net
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>

-- 
Mladen Gogala
Oracle DBA
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Mladen Gogala
  INET: mgogala_at_adelphia.net

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Mon Dec 15 2003 - 23:04:27 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US