The existing Pool2 implementations use equals() to decide if two
objects are the same.

You have to make sure that your equals() implementation returns true
if and only if the objects being compared are the same as far as your
use of them is concerned.
So for example two Integers are equal if they have the same integral
value, but two different StringBuffer instances are never equal.

Once you have determined what constitutes equality for your instances,
make sure that the hash code is coded accordingly, i.e. two objects
that are equal() must have the same hash code.
If this requirment is not met, then the HashMap used internally by
Pool2 will behave unpredictably.

If all RawSession instances are to be regarded as unique (which seems
likely), then define equals and hash code as noted in POOL-283:

https://issues.apache.org/jira/browse/POOL-283?focusedCommentId=14307637&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14307637


On 6 February 2015 at 16:34, Mat Jaggard <matt...@jaggard.org.uk> wrote:
> He didn't create his own hash function, he generated it in eclipse. This is
> better because you get all the testing of other eclipse users without any
> runtime dependencies.
>
> On 6 February 2015 at 16:16, William Speirs <wspe...@apache.org> 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 hash functions?) and might
>> unknowingly fall into a trap here.
>>
>> For example, commons-lang HashBuilder uses 37 as the "prime" and 17 as the
>> initial result... Michael didn't. Maybe he's OK, maybe he's not... but why
>> risk it? Why not just use the library and not reinvent the wheel? (Most
>> valid reason would be not wanting to pull in a whole library for these two
>> functions/classes.)
>>
>> Again, take my advice for what you paid, nothing. :-)
>>
>> Bill-
>>
>> On Fri, Feb 6, 2015 at 11:06 AM, Mat Jaggard <matt...@jaggard.org.uk>
>> wrote:
>>
>> > William - I'm not sure if you noticed, but they didn't hand-make
>> anything.
>> >
>> > On 6 February 2015 at 16:00, William Speirs <wspe...@apache.org> wrote:
>> >
>> > > Why wouldn't you use the HashCodeBuilder? Much simpler:
>> > >
>> > > return new HashCodeBuilder().append(internalId).toHashCode();
>> > >
>> > > Done in 1 line, and probably fewer collisions than your hand-made one.
>> > Same
>> > > with the EqualsBuilder...
>> > >
>> > > If you don't want the dep on commons-lang, then I can understand... but
>> > I'd
>> > > just borrow their internal algo.
>> > >
>> > > My $0.02...
>> > >
>> > > Bill-
>> > >
>> > > On Fri, Feb 6, 2015 at 10:54 AM, Michael Osipov <1983-01...@gmx.net>
>> > > wrote:
>> > >
>> > > > This is what I did:
>> > > > this.internalId = RandomStringUtils.randomAlphanumeric(8);
>> > > >
>> > > > Some Eclipse magic:
>> > > > @Override
>> > > >         public int hashCode() {
>> > > >                 final int prime = 31;
>> > > >                 int result = 1;
>> > > >                 result = prime * result + ((internalId == null) ? 0 :
>> > > > internalId.hashCode());
>> > > >                 return result;
>> > > >         }
>> > > >
>> > > >         @Override
>> > > >         public boolean equals(Object obj) {
>> > > >                 if (this == obj)
>> > > >                         return true;
>> > > >                 if (obj == null)
>> > > >                         return false;
>> > > >                 if (getClass() != obj.getClass())
>> > > >                         return false;
>> > > >                 RawSession other = (RawSession) obj;
>> > > >                 if (internalId == null) {
>> > > >                         if (other.internalId != null)
>> > > >                                 return false;
>> > > >                 } else if (!internalId.equals(other.internalId))
>> > > >                         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 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 recommend using them.
>> > > > > >
>> > > > > > Bill-
>> > > > > >
>> > > > > >
>> > > > > > [1]
>> > > > > >
>> > > >
>> > >
>> >
>> https://commons.apache.org/proper/commons-lang/javadocs/api-3.3.2/org/apache/commons/lang3/builder/EqualsBuilder.html
>> > > > > >
>> > > > > > [2]
>> > > > > >
>> > > >
>> > >
>> >
>> https://commons.apache.org/proper/commons-lang/javadocs/api-3.3.2/org/apache/commons/lang3/builder/HashCodeBuilder.html
>> > > > > >
>> > > > > > On Fri, Feb 6, 2015 at 9:00 AM, Michael Osipov <
>> 1983-01...@gmx.net
>> > >
>> > > > wrote:
>> > > > > >
>> > > > > >> 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 String clientId;
>> > > > > >>         private String serverId;
>> > > > > >>
>> > > > > >> }
>> > > > > >>
>> > > > > >> There won't be any setters but as you see, the cookie store and
>> > > > mutable
>> > > > > >> int might change.
>> > > > > >> Additionally, I did not implement any custom equals and hashCode
>> > > > methods.
>> > > > > >>
>> > > > > >> I have searched the docs and the found and did not find any
>> clear
>> > > > answer
>> > > > > >> which says
>> > > > > >> that pooled objects have to be immutable. Though, I have found
>> > > > POOL-283
>> > > > > >> and POOL-284 which
>> > > > > >> led me to the conclusion that this is a problem because the
>> > objects
>> > > > are
>> > > > > >> stored in a map
>> > > > > >> which relies on equals and hashCode.
>> > > > > >>
>> > > > > >> Does this ultimately mean that I have to override equals and
>> > > hashCode
>> > > > and
>> > > > > >> provide some internal,
>> > > > > >> immutable value something like a UUID? Alternatively, I could
>> > > > retrieve the
>> > > > > >> JSESSIONID from the
>> > > > > >> cookie store and use this as a unique value.
>> > > > > >>
>> > > > > >> Thanks,
>> > > > > >>
>> > > > > >> Michael
>> > > > > >>
>> > > > > >>
>> > > ---------------------------------------------------------------------
>> > > > > >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> > > > > >> For additional commands, e-mail: user-h...@commons.apache.org
>> > > > > >>
>> > > > > >>
>> > > > >
>> > > > >
>> ---------------------------------------------------------------------
>> > > > > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> > > > > For additional commands, e-mail: user-h...@commons.apache.org
>> > > > >
>> > > > >
>> > > >
>> > > > ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> > > > For additional commands, e-mail: user-h...@commons.apache.org
>> > > >
>> > > >
>> > >
>> >
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Reply via email to