GorloPavelРебята. Нет никакой проблемы с id-шниками и т.д у меня. Сейчас все работает как надо. Всем огромнейшее СПАСИБО! Вопрос в следующем... К примеру у меня 2000 подключений. И вдруг они разом отключаются, мне нужно зарегистрировать это в БД. Сейчас при таком раскладе у меня сразу будет 2000 подключений к БД(та самая функция removeSession которую мы тут обсуждали). Я же хочу чтобы на это дело потоки вставали в очередь... Просто реально нет времени объяснять как устроена и что у меня тут за система. Можете посмотреть по моим темам. Еще раз спасибо!Хотите - не хотите, но объяснить, зачем вы хотите ставить потоки в очередь, вам придется :-)
Окей, 2000 соединений оборвалось. Первым делом замечу, что с таким количеством клиентов, да если еще и каждому выделено по потоку, вашему приложению уже будет достаточно плоховасто. При таком количестве потоков здесь с большой вероятностью напрашивается NIO-сервер, который бы разруливал все IO и работу с СУБД в ограниченном небольшом количестве потоков.

Как бы то ни было, пуксай у вас стандартные блокирующие сокеты, и по потоку на соединение. Вдруг две тысячи соединений сдохли. Они все начинают разом ломиться в базу. Но если у вас по уму сделана работа с базой, то есть пул соединений, с которым вы работаете через DataSource, то ничего страшного в этом нет - у вас в каждый момент времени будет работать не более N потоков, где N - количество соединений в пуле. То есть это уже и есть некий аналог очереди.

С другой стороны, если у вас нет никаких проблем с блокировками в СУБД, и по факту закрытия соединения вам надо обновить одну строку в СУБД, и больше никогда ее не трогать, то в целях оптимизации можно задуматься о вынесении логики по "закрытию" сессии в СУБД в отдельный поток, который будет фигачить эти обновления батчами. То есть вам надо застартавать поток, который в бесконечном цикле будет смотреть на какую-нибудь коллекцию. А в этой коллекцию вы складываете все айдишники закрытых коннекторв. А поток либо по таймауту, либо по факту превышения коллекцией определенного размера, забирает эти айдишники из коллекции, и далее либо формирует 1 (один) запрос в СУБД, либо же формирует по одному запросу на каждый ID, как это у вас сделано сейчас, но делает bulk update.

Резюмируя:
1) Если вы паритесь о производительности, то вам надо в первую очередь смотреть в сторону NIO, ибо 2000 потоков от 2000 клиентов могут вообще не выжить у вас. Одновременная запись в базу из этих 2000 потоков является намного меньшим злом, чем сам факт наличия этих потоков в таком огромном количестве.
2) Если все равно хочется заоптимизировать закрытия сессии, то попробуйте сделать так, как я описал выше. Одна коллекция. Один поток в бесконечном цикле, который периодически смотрит на эту коллекцию, и применяет накопленные изменения либо через один большой SQL, либо через множество маленьких SQLей, но в bulk режиме.

Atum1,
Откуда там взяться сервлетам, если к автора нет HTTP?

Atum1 ,
А protobuf здесь причем? :-) Ни HTTP, ни protobuf автору никак не поможет. В его ситуации это просто ненужные навороты сверху, которые не решать ни одной из его проблем. А какие-то вещи могут даже усугубить. Например, если у него сервер работает не по принципу request-response, а сам что-то шлет клиентам без запроса с их стороны.