In the JSSE provider TwoKeyHashMap is used to store objects in the session's application layer data (see javax.net.ssl.SSLSession spec). The name and access control context are used as keys in TwoKeyHashMap (according the spec. the same named values may not be visible across different access control contexts).
Removing of TwoKeyHashMap and using other proposed scenario may slow down the applications that intensively use objects bounded to the SSL session. Surely TwoKeyHashMap may be replaced by other techniques. But it is more effective than using of key wrapper object or 'map of maps'. Removing is a simple solution but I believe TwoKeyHashMap also can be used in other cases to improve performance. Thanks, Boris On 7/24/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:
I would definitely agree these sentiments. Optimization, especially of this kind, should only take place after correct implementation (which I assume we already have) and significant negative side-effects can be shown. This mechanism of optimization just increases the amount of code maintenance and amount of quality assurance. In cases like this, I prefer to lean towards simplicity. In any case, there are numerous other approaches to handling the two-key scenario: * As Alex and other have mentioned, just use a simple wrapper object with correct equals/hashCode. * If you'd rather avoid that object creation, you can use the first key to link to a embedded Map, where you use the second key to link to the desired object. * If the data set is fairly small, like I imagine this is, then you could just use a two-dimensional array and just do brute force searches. This could be optimized further by keeping the array sorted and using binary searches. -Nathan > -----Original Message----- > From: Alex Blewitt [mailto:[EMAIL PROTECTED] > Sent: Sunday, July 23, 2006 3:22 AM > To: [email protected] > Subject: Re: Re: [classlib] TwoKeyHashMap > > I don't think that it makes sense to maintain a completely separate > data structure just because there's a pair of keys. An object that > holds two values will do the job just as well, and there should be no > problem with an object being created, used for a lookup, and then > recycled in the nursery generation. On the other hand, having a > separate algorithm is more likely to result in duplicated information > and maintenance. > > This sounds like premature optimisation to me. After all, how many > lookups are being performed in the crypto framework? If it's just a > pairing of (say) provider/hash algorithm, how frequently is it being > used? Do we have any stats that show the bottleneck is on the access > of a value from the hashmap? > > Alex. > > On 23/07/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > It's created for performance optimization. Without it a new object has > to be > > created every time a record is seeked in a hashmap. > > > > it's used in crypto framework and JSSE provider. > > > > Thanks, > > Mikhail > > > > 2006/7/22, Geir Magnusson Jr <[EMAIL PROTECTED]>: > > > If it's not being used anywhere, and if no one claims it, +1 > > > > > > (and if it's being used and can be replaced.... +1) > > > > > > Nathan Beyer wrote: > > > > I'm all for removing it. The last time I looked through that code I > came to > > > > the same conclusion your questions infer. If I recall correctly, > some of the > > > > actual Map interface methods won't even work correctly if used. > Also, I > > > > believe the actual keys were just Strings, so concatenated Strings > could > > > > even be used. > > > > > > > > -Nathan > > > > > > > >> -----Original Message----- > > > >> From: Tim Ellison [mailto:[EMAIL PROTECTED] > > > >> Sent: Friday, July 21, 2006 11:52 AM > > > >> To: harmony-dev > > > >> Subject: [classlib] TwoKeyHashMap > > > >> > > > >> Does anyone know why we have a TwoKeyHashMap [1] utility class? > > > >> > > > >> I've only looked at it briefly, but I'm left wondering why the > author > > > >> chose to write all that rather than use a regular HashMap with an > object > > > >> that combines the 'TwoKey's? > > > >> > > > >> There may be a subtlety I missed. Anyone know? > > > >> > > > >> [1] > > > >> > http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/mod > > > >> > ules/luni/src/main/java/org/apache/harmony/luni/util/TwoKeyHashMap.java?vi > > > >> ew=co > > > >> > > > >> Regards, > > > >> Tim > > > >> > > > >> -- > > > >> > > > >> Tim Ellison ([EMAIL PROTECTED]) > > > >> IBM Java technology centre, UK. > > > >> > > > >> ------------------------------------------------------------------- > -- > > > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > > > >> To unsubscribe, e-mail: harmony-dev- > [EMAIL PROTECTED] > > > >> For additional commands, e-mail: harmony-dev- > [EMAIL PROTECTED] > > > > > > > > > > > > -------------------------------------------------------------------- > - > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: harmony-dev- > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Best regards, Boris Kuznetsov Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
