Any thoughts on the first point about executing multiple SQL queries on physical connection creation?
On 09-Feb-2012, at 7:05 PM, Pid <p...@pidster.com> wrote: > On 09/02/2012 12:56, amit shah wrote: >> One more comment below about oracle UCP. > > <snip> > >>>>>> The pool returns members at random, so how would you know which cached >>>>>> credentials you were getting? >>>>>> >>>>>> The credentials which are passed to the getConnection(String username, >>>>> String password) method. When we configure the same pool to be used for >>>>> multiple schema's the pool will *not *be configured with default >>>> username >>>>> password. >>>> >>>> OK, so you create a bunch of connections with various credentials, you >>>> want to cache those connections and only return them if the creds match >>>> for the new request? >>>> >>>> So you're basically creating an uncontrolled pool per cred pair, inside >>>> the outer pool which is controlled? >>>> >>> >>> Yes right. > > So why not create multiple controlled pools & not run into availability > problems? > > > <snip> > >>>> What overhead? >>>> >>> >>> The application server and database server resources (memory, cpu etc) for >>> keeping the connections open? > > That's a total connection count dependent metric. > > So the overhead is virtually the same regardless of whether you have 5 > pools or 1, if you have the same total number of connections. > > >>>> For e.g. If we have 5 tenants with 5 >>>>> pools configured with 10 min pool size, we would have min 50 connections >>>>> always open to the database server. This count would be for each >>>>> application server. If we had the same pool for all 5 tenants, there >>>> would >>>>> be just 10 connections open per application server. >>>> >>>> There's a flaw in your logic. >>>> >>>> In your example there may be zero connections open for a given tenant >>>> because they use a shared pool. >>>> >>>> So you might has well have separate pools with the minimum set to 2 and >>>> still have more connections guaranteed per tenant, and the 10 you were >>>> aiming for. >>>> >>>> Worse, if you hit your max with other tenants, a remaining tenant might >>>> not be able to get a connection at all, thus failing to address one of >>>> the key requirements in a multi-tenant system - guaranteed availability. >>>> >>>> Probably true when all the tenants are actively used. As I said, there is >>> always a flexibility in the configuration to use a separate pool for a >>> particular tenant. > > That should be the default IMO. You're asking for trouble otherwise. > > >>>>> Also the application can always provide a configuration flexibility to >>>>> allow a tenant to use a separate pool instead of sharing it with other >>>>> tenants (like I said above). >>>>> >>>>> This flexibility is provided by the Oracle Universal Connection >>>>> Pool<http://docs.oracle.com/cd/E11882_01/java.112/e12265/toc.htm> >>>> >>>> So if that's a better fit for your requirement, why not use it? >>>> >>>> >> It provides the feature I mentioned about by has lock contention issues. >> Tomcat 7 jdbc pool seems to be better and hence I was trying it out. > > ! > > <snip> > >>>> If you are programmatically registering the pool, can you not just >>>> register it with the MBean server yourself? >>>> >>>> Ok I will try this and provide an update. > > Cool. > > > p > > > > > -- > > [key:62590808] > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
