On Mon, Feb 09, 2015 at 06:37:32AM -0500, James Carman wrote:
Premature optimization. UUIDs aren't slow.
Could be indeed. Depends on the specific use case.
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For
On 09/02/2015 18:47, Adrian Crum wrote:
I have been reading this thread for days, and I am confused.
I might be wrong, but it seems to me the discussion started with a
simple problem - an object borrowed from an object pool could not be
returned to the pool because the object's hash value
Premature optimization. UUIDs aren't slow.
On Monday, February 9, 2015, Matthew Hall mh...@mhcomputing.net wrote:
On Sun, Feb 08, 2015 at 11:07:59AM +0100, Michael Osipov wrote:
How would you propose to use it?
I would still need a random number or do you recomment to use a static
one
On 9 February 2015 at 05:07, Matthew Hall mh...@mhcomputing.net wrote:
On Sun, Feb 08, 2015 at 11:07:59AM +0100, Michael Osipov wrote:
How would you propose to use it?
I would still need a random number or do you recomment to use a static one
and simply increment during the lifetime of the
On Fri, Feb 06, 2015 at 04:54:25PM +0100, Michael Osipov wrote:
This is what I did:
this.internalId = RandomStringUtils.randomAlphanumeric(8);
When doing these types of tricks to assign transaction ID's or serial numbers
to objects / log messages / etc., I'm more of a fan of using AtomicLong.
Am 2015-02-06 um 22:13 schrieb Matthew Hall:
On Fri, Feb 06, 2015 at 04:54:25PM +0100, Michael Osipov wrote:
This is what I did:
this.internalId = RandomStringUtils.randomAlphanumeric(8);
When doing these types of tricks to assign transaction ID's or serial numbers
to objects / log messages /
Am 2015-02-06 um 19:21 schrieb Phil Steitz:
On 2/6/15 10:16 AM, sebb wrote:
The existing Pool2 implementations use equals() to decide if two
objects are the same.
As of pool 2.3.
You have to make sure that your equals() implementation returns true
if and only if the objects being compared
Am 2015-02-06 um 17:14 schrieb James Carman:
Try UUID.randomUUID().toString() rather than RandomStringUtils if you
really want unique keys.
Aren't both pseudo random?
I won't have more than 30 sessions in parallel. Do you think that a
collision might happen?
Michael
Am 2015-02-06 um 17:14 schrieb James Carman:
Try UUID.randomUUID().toString() rather than RandomStringUtils if you
really want unique keys.
Aren't both pseudo random?
I won't have more than 30 sessions in parallel. Do you think that a
collision might happen?
Michael
Am 2015-02-06 um 19:21 schrieb Phil Steitz:
On 2/6/15 10:16 AM, sebb wrote:
The existing Pool2 implementations use equals() to decide if two
objects are the same.
As of pool 2.3.
You have to make sure that your equals() implementation returns true
if and only if the objects being compared
You aren't guaranteed for them not to collide. So, yes, it could happen.
On Saturday, February 7, 2015, Michael Osipov 1983-01...@gmx.net wrote:
Am 2015-02-06 um 17:14 schrieb James Carman:
Try UUID.randomUUID().toString() rather than RandomStringUtils if you
really want unique keys.
On Feb 7, 2015, at 2:23 AM, Michael Osipov 1983-01...@gmx.net wrote:
Am 2015-02-06 um 19:21 schrieb Phil Steitz:
On 2/6/15 10:16 AM, sebb wrote:
The existing Pool2 implementations use equals() to decide if two
objects are the same.
As of pool 2.3.
You have to make sure that your
Or not implement them at all since this is exactly what the Object class
will do for you.
On Sunday, February 8, 2015, sebb seb...@gmail.com wrote:
Why don't you just implement equals() and hashCode() as noted here [1] ?
This will allow the use of Pool2 and guarantee that different
instances
On 8 February 2015 at 15:09, James Carman ja...@carmanconsulting.com wrote:
Or not implement them at all since this is exactly what the Object class
will do for you.
Yes, that is true for the sample RawSession class shown at the start
of the thread.
However if the class were changed to inherit
Am 2015-02-08 um 14:34 schrieb sebb:
Why don't you just implement equals() and hashCode() as noted here [1] ?
This will allow the use of Pool2 and guarantee that different
instances are treated as different, regardless of mutabiity.
No need to generate unique ids for each instance.
Pool2
Am 2015-02-08 um 13:12 schrieb James Carman:
You aren't guaranteed for them not to collide. So, yes, it could happen.
But UUID is neither but the probability is exteremely low. Is that what
you tried to say?
On Saturday, February 7, 2015, Michael Osipov 1983-01...@gmx.net wrote:
Am
On 8 February 2015 at 20:38, Michael Osipov 1983-01...@gmx.net wrote:
Am 2015-02-08 um 14:34 schrieb sebb:
Why don't you just implement equals() and hashCode() as noted here [1] ?
This will allow the use of Pool2 and guarantee that different
instances are treated as different, regardless of
On Sun, Feb 08, 2015 at 11:07:59AM +0100, Michael Osipov wrote:
How would you propose to use it?
I would still need a random number or do you recomment to use a static one
and simply increment during the lifetime of the application?
If so, thing might cause trouble in the future because I
I'd think adding a UUID then overriding equals and hashCode would do the
trick. To aid you in doing this, commons-lang has EqualsBuilder [1] and
HashCodeBuilder [2], I highly recommend using them.
Bill-
[1]
))
return false;
return true;
}
Gesendet: Freitag, 06. Februar 2015 um 16:47 Uhr
Von: James Carman ja...@carmanconsulting.com
An: Commons Users List user@commons.apache.org
Betreff: Re: [POOL2] Pooling mutable objects
Or just let your IDE
Or just let your IDE generate the methods.
On Fri, Feb 6, 2015 at 9:05 AM, William Speirs wspe...@apache.org wrote:
I'd think adding a UUID then overriding equals and hashCode would do the
trick. To aid you in doing this, commons-lang has EqualsBuilder [1] and
HashCodeBuilder [2], I highly
. Februar 2015 um 16:47 Uhr
Von: James Carman ja...@carmanconsulting.com
An: Commons Users List user@commons.apache.org
Betreff: Re: [POOL2] Pooling mutable objects
Or just let your IDE generate the methods.
On Fri, Feb 6, 2015 at 9:05 AM, William Speirs wspe...@apache.org wrote:
I'd think
;
return true;
}
Gesendet: Freitag, 06. Februar 2015 um 16:47 Uhr
Von: James Carman ja...@carmanconsulting.com
An: Commons Users List user@commons.apache.org
Betreff: Re: [POOL2] Pooling mutable objects
Or just let your IDE generate the methods
false;
return true;
}
Gesendet: Freitag, 06. Februar 2015 um 16:47 Uhr
Von: James Carman ja...@carmanconsulting.com
An: Commons Users List user@commons.apache.org
Betreff: Re: [POOL2] Pooling mutable objects
Or just let your IDE
...@carmanconsulting.com
An: Commons Users List user@commons.apache.org
Betreff: Re: [POOL2] Pooling mutable objects
Or just let your IDE generate the methods.
On Fri, Feb 6, 2015 at 9:05 AM, William Speirs wspe...@apache.org
wrote:
I'd think adding a UUID
Hi folks,
I am developing a session pool for an HTTP backend which is requested with the
fabulous HttpClient.
The session object is this:
public class RawSession {
private CookieStore cookieStore;
private String logId;
private MutableInt requestId;
private
Hi William,
William Speirs wrote:
I'm not sure I understand your comment Mat. From what I can tell, Michael
made his own hash function. That's fine, but *might* have unexpected
collision issues. Might not too... I don't know. My guess though is that
he's not an expert (who is an expert on
, 06. Februar 2015 um 16:47 Uhr
Von: James Carman ja...@carmanconsulting.com
An: Commons Users List user@commons.apache.org
Betreff: Re: [POOL2] Pooling mutable objects
Or just let your IDE generate the methods.
On Fri, Feb 6, 2015 at 9:05 AM, William Speirs wspe...@apache.org
wrote:
I'd
28 matches
Mail list logo
