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
> 
> 
> 
> [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
> 
> 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (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).

Reply via email to