Как осуществить субж?
Например

Что мне нужно:
Возможность выдернуть юзера по ИД и по Сессии, будут какие предложения? А то я уже совсем запутался...

Используй MultiKey из Jakarta Commons Collections.

Гм, а сделать свой Key объект, который состоит из инта и стринга?
Определив hashcode, equals() 

И по сессии И по айдишнику - тогда можно просто сделать свой объектик, как и сказал chief39, а вот если ИЛИ по сессии ИЛИ по айдишнику, тогда не знаю, видимо, ка сказал LSD ... Тоже гляну на это мультикей

ПыСЫ
в любом случае кто мешает при добавлении пихать в два хэшмапа, а при поиске пользоваться нужным

Это сообщение отредактировал(а) y3u - 12.2.2007, 17:16

y3u, 
Нужно ИЛИ по сессии, ИЛИ по айди.
Multikey не подходит, т.к  там сразу по обоим критериям.
Насчет двух  хешмапов думал, но подумал, что есть более правильное решение.

Так И или ИЛИ? 
Если ИЛИ, то можно и одной HashMap обойтись.

Но будет геморой с удалением значений. Например мы хотим удалить запись по ID, но нужно также будет найти его сессию, чтобы удалить и ее.

а вот и нельзя  Есть известное утверждение, что у двух идентичных объектов должен быть идентичный хешкод, но, если мы имеем два идентичных хешкода - отсюда НЕ следует, что объекты идентичные. Вполне легальны ситуации: коллекция не типизированная - значит хеши по стринге и по интеджеру могут совпасть, а если типизированная, то так сделать не даст компилятор 

Это сообщение отредактировал(а) y3u - 13.2.2007, 13:20

И какое это имеет отношение, к тому что я сказал?

прямое



скажем, в 1.4 SDK посмотри как работает get(Object key) у HashMap... у тебя медленный код, т.к. хеши id и value могут быть одинаковыми, а реально объекты, находящиеся по этим ключам - разные

вобщем, ладно... это оффтоп 

Это сообщение отредактировал(а) y3u - 13.2.2007, 15:22

Вообще то, я прелагал искать value или по id, или по name  
И хеш код value в данном случае вообще неважен.

Добавлено @ 16:04 

Я знаю как работает HashMap. Совпадение хешей маловероятно, но не смертельно, в реальных задачах они все равно совпадают.

Почему они вдруг разные? И там и там указатель на один и тот же обьект.

Пишешь что-то вроде:


Добавлено @ 16:06 

"Медленность" зависит от соотношения размера таблицы к количеству элементов в ней. Тут Ява сама подберёт оптимальную величину.

да блин, я описАлся, я имел в виду, конечно, name, а не value... Я вообще только о ключх говорю и все  Не буду оффтопить дальше, скажу лишь, по поводу реальности задачи, что вероятность совпадения хешей и id и name в данном случае велика, причем вероятность увеличивается с ростом количества пользователей. Просто имеет смысл избегать нежелательных проблем с производительностью в тех случаях, где их реально можно избегать заранее просто и легко. Там же сначала берется хеш, достается индекс из таблицы, потом икуалс смотрится, если не совпадает ьерется следующее совпадение по хешу... Вы же не храните в одной банке соль и сахар на кухне...

Это сообщение отредактировал(а) y3u - 13.2.2007, 16:23

Не больше, чем совпадение двух разных name.


Не верно. С увеличением количества пользователей наша таблица будет расширятся и уменьшать таким образом вероятность совпадений.
(Размер кстати можно и изначально побольше задать)

Для практически равномерного распределения размер таблицы должен быть примерно N+20% где N - количество элементов хранимых таблице. Что это за объекты - не важно


Нет, но книги разных авторов за разное время спокойно стоят на одной полке. И name и id - то и другое для хэштаблицы - объекты с калькулируемым идентификатором.

Написал класс, по совету chief39, 


Добавляю в HashMap так:


Как мне бонально проверить на наличие сессии?

не помогает

аналогично

Это сообщение отредактировал(а) Opik - 27.2.2007, 23:28

При такой реализации DoubleKey - никак. Точнее, никак за счёт containsKey. Простой перебор множества ключей сработает, но это простой перебор. В качестве заплатки сработает, если будешь пихать в мапу "пустышку" именно для возможности поиска по сессии:

Искать тогда так:

null вместо идентификатора пихать нельзя, т.к. будет падать на NullPointer.