On 11/06/2011 18:18, Phil Steitz wrote:
> On 6/11/11 2:54 AM, Mark Thomas wrote:
>> On 11/06/2011 08:44, Phil Steitz wrote:
>> 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 Li
On 6/11/11 4:31 AM, Mark Thomas wrote:
> On 11/06/2011 12:26, Honton, Charles wrote:
>> 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 performanc
On 6/11/11 2:54 AM, Mark Thomas 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 holdi
On 11/06/2011 12:26, Honton, Charles wrote:
> 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.
I suggest you take a look in th
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" wrote:
>On 11/06/2011 08:44, Phil Steitz
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 cli
On 6/10/11 2:38 PM, Mark Thomas wrote:
> On 10/06/2011 22:33, Gary Gregory wrote:
>> On Jun 10, 2011, at 13:47, Mark Thomas wrote:
>>
>>> On 09/06/2011 17:47, Phil Steitz wrote:
I guess I "want it both ways" here. We already have a use case for
tracking instances - abandoned connection
On 10/06/2011 22:33, Gary Gregory wrote:
> On Jun 10, 2011, at 13:47, Mark Thomas wrote:
>
>> On 09/06/2011 17:47, Phil Steitz wrote:
>>> I guess I "want it both ways" here. We already have a use case for
>>> tracking instances - abandoned connection tracking in DBCP and
>>> *lots* of requests a
On Jun 10, 2011, at 13:47, Mark Thomas wrote:
> On 09/06/2011 17:47, Phil Steitz wrote:
>> I guess I "want it both ways" here. We already have a use case for
>> tracking instances - abandoned connection tracking in DBCP and
>> *lots* of requests and practical uses for holding references to
>> in
On 6/10/11 10:46 AM, Mark Thomas wrote:
> On 09/06/2011 17:47, Phil Steitz wrote:
>> I guess I "want it both ways" here. We already have a use case for
>> tracking instances - abandoned connection tracking in DBCP and
>> *lots* of requests and practical uses for holding references to
>> instances
On 09/06/2011 17:47, Phil Steitz wrote:
> I guess I "want it both ways" here. We already have a use case for
> tracking instances - abandoned connection tracking in DBCP and
> *lots* of requests and practical uses for holding references to
> instances in circulation (mostly from dbcp, but I recall
On 6/9/11 9:05 AM, Mark Thomas wrote:
> On 09/06/2011 15:48, Gary Gregory wrote:
>> Hi All:
>>
>> I would like to understand the requirements better:
>>
>> - Is this for pool1 and/or pool2? It seems like a big change for pool1 that
>> should be in a 1.6 (not 1.5.x)
> pool2. No plans for this change
On 09/06/2011 15:48, Gary Gregory wrote:
> Hi All:
>
> I would like to understand the requirements better:
>
> - Is this for pool1 and/or pool2? It seems like a big change for pool1 that
> should be in a 1.6 (not 1.5.x)
pool2. No plans for this change in pool1.
> - Do we have real user stories
On 09/06/2011 14:50, sebb wrote:
> On 9 June 2011 14:41, Mark Thomas wrote:
>> On 09/06/2011 10:01, Julien Aymé wrote:
>>> 2011/6/9 Mark Thomas :
On 09/06/2011 04:39, Phil Steitz wrote:
> Code in trunk now does not work when distinct pooled instances are
> equal - i.e., if a factory p
Hi All:
I would like to understand the requirements better:
- Is this for pool1 and/or pool2? It seems like a big change for pool1 that
should be in a 1.6 (not 1.5.x)
- Do we have real user stories for this new req? Or is this a theoretical
nicety?
Thank you,
Gary
On Thu, Jun 9, 2011 at 9:50 AM
On 9 June 2011 14:41, Mark Thomas wrote:
> On 09/06/2011 10:01, Julien Aymé wrote:
>> 2011/6/9 Mark Thomas :
>>> On 09/06/2011 04:39, Phil Steitz wrote:
Code in trunk now does not work when distinct pooled instances are
equal - i.e., if a factory produces instances A and B and
A.equ
On 09/06/2011 10:01, Julien Aymé wrote:
> 2011/6/9 Mark Thomas :
>> On 09/06/2011 04:39, Phil Steitz wrote:
>>> Code in trunk now does not work when distinct pooled instances are
>>> equal - i.e., if a factory produces instances A and B and
>>> A.equals(B), this causes problems. I think this situ
2011/6/9 Mark Thomas :
> On 09/06/2011 04:39, Phil Steitz wrote:
>> Code in trunk now does not work when distinct pooled instances are
>> equal - i.e., if a factory produces instances A and B and
>> A.equals(B), this causes problems. I think this situation should
>> be allowed - i.e. it is an una
On 09/06/2011 04:39, Phil Steitz wrote:
> Code in trunk now does not work when distinct pooled instances are
> equal - i.e., if a factory produces instances A and B and
> A.equals(B), this causes problems. I think this situation should
> be allowed - i.e. it is an unacceptable restriction to put
On 9 June 2011 04:39, Phil Steitz wrote:
> Code in trunk now does not work when distinct pooled instances are
> equal - i.e., if a factory produces instances A and B and
> A.equals(B), this causes problems. I think this situation should
> be allowed - i.e. it is an unacceptable restriction to pu
Code in trunk now does not work when distinct pooled instances are
equal - i.e., if a factory produces instances A and B and
A.equals(B), this causes problems. I think this situation should
be allowed - i.e. it is an unacceptable restriction to put on object
factories that distinct the poolable o
21 matches
Mail list logo
