Return-Path: X-Original-To: apmail-tomcat-users-archive@www.apache.org Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BE66E92BC for ; Thu, 9 Feb 2012 16:17:42 +0000 (UTC) Received: (qmail 44784 invoked by uid 500); 9 Feb 2012 16:17:39 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 44692 invoked by uid 500); 9 Feb 2012 16:17:38 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 44683 invoked by uid 99); 9 Feb 2012 16:17:38 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Feb 2012 16:17:38 +0000 X-ASF-Spam-Status: No, hits=-0.5 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of amits.84@gmail.com designates 209.85.210.45 as permitted sender) Received: from [209.85.210.45] (HELO mail-pz0-f45.google.com) (209.85.210.45) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Feb 2012 16:17:30 +0000 Received: by dadp14 with SMTP id p14so1634777dad.18 for ; Thu, 09 Feb 2012 08:17:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=jwWkMq4+FJve62j82Plcb0V7uAKyHgXkkaZf5/TtG1M=; b=fhXcwmPATMgtn8+aP9NWhyZdc3cwauBvCT7hidd2c8HK3eVMqDya7N+98mnEc3PhVb WxmczlOZWIGtdQGJPqgoti7jygSyMfgjK3k0OjFMaELW2A6o4BU59HV67QrW4J87FP7r F7K+jfUgedHT64xCFcCXxnHyLLJ3v1gHKTgqc= Received: by 10.68.242.42 with SMTP id wn10mr7388157pbc.25.1328804228987; Thu, 09 Feb 2012 08:17:08 -0800 (PST) Received: from [192.168.2.2] ([116.75.1.143]) by mx.google.com with ESMTPS id x8sm7154652pbr.11.2012.02.09.08.17.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Feb 2012 08:17:07 -0800 (PST) References: <4F32614D.2070806@pidster.com> <4F327C22.2090302@pidster.com> <4F329989.8060503@pidster.com>

<4F33CB99.5000906@pidster.com> In-Reply-To: <4F33CB99.5000906@pidster.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <7D4B0E7D-6AED-4FBA-8262-7D80ECC64DC4@gmail.com> Cc: Tomcat Users List X-Mailer: iPad Mail (9A405) From: Amit Subject: Re: Using Tomcat7 JDBC Connection Pool Date: Thu, 9 Feb 2012 21:51:12 +0530 To: Tomcat Users List X-Virus-Checked: Checked by ClamAV on apache.org Any thoughts on the first point about executing multiple SQL queries on phys= ical connection creation? On 09-Feb-2012, at 7:05 PM, Pid wrote: > On 09/02/2012 12:56, amit shah wrote: >> One more comment below about oracle UCP. >=20 > >=20 >>>>>> The pool returns members at random, so how would you know which cache= d >>>>>> credentials you were getting? >>>>>>=20 >>>>>> The credentials which are passed to the getConnection(String username= , >>>>> String password) method. When we configure the same pool to be used fo= r >>>>> multiple schema's the pool will *not *be configured with default >>>> username >>>>> password. >>>>=20 >>>> 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? >>>>=20 >>>> So you're basically creating an uncontrolled pool per cred pair, inside= >>>> the outer pool which is controlled? >>>>=20 >>>=20 >>> Yes right. >=20 > So why not create multiple controlled pools & not run into availability > problems? >=20 >=20 > >=20 >>>> What overhead? >>>>=20 >>>=20 >>> The application server and database server resources (memory, cpu etc) f= or >>> keeping the connections open? >=20 > That's a total connection count dependent metric. >=20 > 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. >=20 >=20 >>>> For e.g. If we have 5 tenants with 5 >>>>> pools configured with 10 min pool size, we would have min 50 connectio= ns >>>>> 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. >>>>=20 >>>> There's a flaw in your logic. >>>>=20 >>>> In your example there may be zero connections open for a given tenant >>>> because they use a shared pool. >>>>=20 >>>> 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. >>>>=20 >>>> 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= . >>>>=20 >>>> Probably true when all the tenants are actively used. As I said, there i= s >>> always a flexibility in the configuration to use a separate pool for a >>> particular tenant. >=20 > That should be the default IMO. You're asking for trouble otherwise. >=20 >=20 >>>>> 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). >>>>>=20 >>>>> This flexibility is provided by the Oracle Universal Connection >>>>> Pool >>>>=20 >>>> So if that's a better fit for your requirement, why not use it? >>>>=20 >>>>=20 >> 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. >=20 > ! >=20 > >=20 >>>> If you are programmatically registering the pool, can you not just >>>> register it with the MBean server yourself? >>>>=20 >>>> Ok I will try this and provide an update. >=20 > Cool. >=20 >=20 > p >=20 >=20 >=20 >=20 > --=20 >=20 > [key:62590808] >=20 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org