Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of Charles_Honton@intuit.com
 designates 12.149.175.12 as permitted sender)
DomainKey-Signature: s=default; d=intuit.com; c=nofws; q=dns;
  h=X-SBRS:X-IronPort-AV:Received:Received:Received:Received:
   From:To:Subject:Thread-Topic:Thread-Index:Date:Message-ID:
   In-Reply-To:Accept-Language:Content-Language:
   X-MS-Has-Attach:X-MS-TNEF-Correlator:user-agent:
   x-originating-ip:Content-Type:Content-ID:
   Content-Transfer-Encoding:MIME-Version:Return-Path:
   X-OriginalArrivalTime:X-OriginalArrivalTime;
  b=PbzVB4ypf4Fho6UvaYdeoWFcQgE+HJYTzqWWcUFB7ZC0e89c2NmR+scd
   tnIH3yhraO1a22MglPGTnK+6d/IGwRtL6/7huLueEthK1ICRab6F0dsyW
   IgKMk9pCXt5AqDy;
From: "Honton, Charles" <Charles_Honton@intuit.com>
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [pool] equal instances
Thread-Topic: [pool] equal instances
Thread-Index: 
 AQHMJlboeBiR9RXrnk69gULUz4BVmpS1JJ0AgAALuQCAAE5KAIAAAoQAgAAQJYCAABVigIAAC+MAgAGitACAAD9wgIAAAXuAgACpMoCAACSIAP//1myA
Date: Sat, 11 Jun 2011 11:26:08 +0000
Message-ID: <CA18C85D.9D1E%charles_honton@intuit.com>
In-Reply-To: <4DF33B70.5010000@apache.org>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.10.0.110310
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D1AE8FD94A7C394DAB1DB8E77658911D@intuit.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Please look at java.util.IdentityHashMap again.  I think it does
everything you're looking for except concurrent access.  Given other
requirements, I'm not sure a ConcurrentHashMap will buy much performance
anyway.

chas


On 6/11/11 5:54 AM, "Mark Thomas" <markt@apache.org> wrote:

>On 11/06/2011 08:44, Phil Steitz wrote:
>> I have looked at this some more and I think we have two choices,
>> depending on how much we want to be able to do in terms of
>> monitoring and instance management.  The simplest solution is to
>> enable only holding references to instances checked out to clients,
>> but no tracking of last active times, etc. by the pool itself
>> (leaving this to the pooled objects themselves, as
>> AbandonedObjectPool does now).  That could be done with less
>> ambitious _allObjects and PoolableObject classes.  Actually,
>> _allObjects would go away, replaced by a List of _circulatingObjects
>> (like AbandonedObjectPool trace) and PoolableObject would really
>> only maintain state for idle instances or instances undergoing
>> lifecycle transitions.
>
>The problem with a List and objects where A.equals(B) is that we'll have
>to iterate through the list testing objects for equality when an object
>is returned in order to remove the right object. That will be slow. (If
>we want to prevent the same object being returned multiple times).
>
>> If we want to be able to track things like last active time (as the
>> trunk code now enables), we need to be able to identify returning
>> objects uniquely.  That means either we impose the factory
>> discernibility requirement or use system identity hashcodes.
>>=20
>> I would like to keep the monitoring / management options open, so my
>> vote is for the second option.  I wonder, though, if it makes sense
>> to keep the base implementation simple (and a little faster) and
>> restrictive and provide the equals-tolerant functionality in a
>> subclass or via a config option.
>
>I too think that the second option is the way to go using system
>identity hashcodes. I'm not sure that the first option will be faster
>since iterating through the List of circulating objects is likely to be
>slower than generating a system identity hashcode and doing a lookup in
>a Map. If testing pool2/dbcp2 shows that the system identity hashcode
>makes it significantly slower than Tomcat's jdbc-pool then we can look
>at this again.
>
>Mark
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>For additional commands, e-mail: dev-help@commons.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org