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 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. Also, hash codes should not change between the time that an object is borrowed from the pool and subsequently returned. Again, for pool 2.0-2.3 (latest as of this post), objects under management by the pool are kept in a hashmap keyed on the objects themselves, so mutability that changes hashcodes (and / or equality) can cause problems. See the discussion on POOL-284. These problems do not impact earlier (1.x) versions of Commons Pool. > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
