I agree that the implementation of a connection pool is dependent on the
app server, which for various reasons, might choose not to use the
connection pool inherent in the programming interface, whether it's OCI
or JDBC. One reason may be that the app server already has its own
connection pool before 9i and the developers feel it's not worth the
risk to change their implementation to use the OCI connection pool.
Another reason may be that their app server has to work with both 8i and
9i servers and if they use a feature only present in the 9i client, it
most likely will not work properly with an 8i server.
mgogala_at_adelphia.net wrote:
> 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).
>>
>
>
--
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).
Received on Tue Dec 16 2003 - 00:29:25 CST
