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).