Добрый день!

Собственно сабж: есть список пользователей (List<Long>) в который при логине вносится ID. В отдельном потоке через определенный интервал времени просматривается этот список и инициируется событие (update row) для каждого ID.

Планирую использовать java.util.Timer и java.util.TimerTask. И через определенный интервал создавать в цикле отдельные потоки для апдейта для каждого ID'шника.

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

Спасибо!

Сам ты nastya

Вот код, который набросал (пинать не сильно, раньше особо с потоками не работал)




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

Если поток активный (все еще проадпдейтится запись) для пользователя с user_id=1, то при попытке создания нового потока для него же, пропускать до следующего цикла.

В коде поставил Thread.currentThread().interrupt(); для принудительного "кила" потока - не факт что правильно.

вадяэто ноги растут от сюда 21667055
Нее, там другая задача )))

Blazkowicz,нет, 7, просто, какие примеры нагуглил ))) так и написал

Petro123qi_ip,
Зачем тебе потоки, да ещё на select?
Чтобы в определенный момент времени можно было апдейтить записи по каждому пользователю, который появляется в списке.
Там идет сначала select и потом update.

Petro123qi_ipПока не знаю, как лучше контролировать, чтобы в каждый момент времени создавался только один поток для одного пользователя:один на всех и цикл
ИМХО, не совсем подходит.
Если еще дальше углубиться, то суть в чем: что в базе периодически появляются новые записи, например, со статусом 0 для апдейта на статус 1 для любого пользователя. В списке userlist хранятся онлайн пользователи (это при работе с вебсокетом).

Соответственно, они "входят и выходят". И для тех, которые онлайн нужно проапдейтить новые записи максимально быстро. Поэтому решил, что с потоками будет быстрее. Так как если список будет слишком большой, последний пользователь из списка будет долго ждать, когда до него дойдет очередь.
А с потоками получается так, что крутится какой-то процесс, который периодически смотрит этот список и создает отдельные микрозадачи каждые в своем потоке.

Blazkowiczqi_ipИ для тех, которые онлайн нужно проапдейтить новые записи максимально быстро. Поэтому решил, что с потоками будет быстрее.
Не факт что будет быстрее. Пула потоков нет. Обновить несколько записей БД одним запросом на много быстрее чем сделать тоже самое из кучи конкурирующих запросов.
Нюанс в том, что я не могу это объединить в общий запрос для апдейта, так как по каждой записи, которую сделал select по сокету каждому пользователю отправляю сообщение.
С пулом потоков будет быстрее?

Petro123qi_ipсоздает отдельные микрозадачи каждые в своем потоке.хотя бы время озвучил микрозадачи и задержку таймера.
Сложно сказать, так как пока в режиме теста (подбор возможных вариантов). По сути, задержка таймера по минимуму. Время на микрозадачу: селект записи по userId, считывание данных строки в переменную, отправка по вебсокету этих данных, апдейт статуса строки - конец задачи. Сколько займет времени пока не замерял - нужно чем быстрее, тем лучше.

Petro123qi_ip,
Если врубить второй кэш в хибере, то и в базу не надо лезть).
...
Преждевременная оптимизация называется.
Тесты нужны.

К сожалению, хибер тут не используется (((

Blazkowiczqi_ipНюанс в том, что я не могу это объединить в общий запрос для апдейта, так как по каждой записи, которую сделал select по сокету каждому пользователю отправляю сообщение.
С пулом потоков будет быстрее?
И что, транзакции висят пока сообщение не будет отправлено? Только потом комитяться? Это же пипец базе, залочится всё нахрен.
Делаю селект, отправляю сообщение с данными из селекта, делаю апдейт. При селекте, разве база лочится?


Petro123BlazkowiczИ что, транзакции висят пока сообщение не будет отправлено?
+1
Аффтар!
Решение без коммита:
При новой сессии отпраляем все что спросит.
При каждой отправке пишем в оперативку тайштамп время последней отправки.
И потом общий апдейт?

BlazkowiczТогда всё ещё не понятно почему нужно делать апдейты в отдельных потоках?
Получили список ID. Сделали по нему выборку. Отправили всем сообщения. Потом батч-апдейтом накатили всем то кого пришло подтверждение.

Вы изобретаете потоки там где они не нужны. Потоки вам по факту нужны только чтобы отправлять сообщения.
Понятно, согласен, что для апдейтить в потоке может быть не правильно, единственный нюанс который я вижу, что апдейты будут не успевать за отправками сообщениями, но тут чисто ИМХО, так как еще не протестировал.

Petro123qi_ipИ потом общий апдейт?о чем?
Незачем сохранять в базу вообще.
Мне нужно проапдейтить запись, для кого было отправлено сообщение.

maytonДружище. Я читаю уже много постов и не пойму какая решается задача.
Классическая работа с бд в режиме OLTP не требует каких то фоновых потоков и ухищрений.
Либо у тебя в бд уже есть проблема и ее надо решать в бд. Плодить потоки можно в java бесконечно много но это не помогает работе БД..
Потоки появились из-за необходимости через вебсокет отправлять сообщения определенным пользователям с максимальной скоростью доставки, а апдейтить, как уже написал Blazkowicz можно не в потоке, а батч-апдейтом.

Petro123qi_ipМне нужно проапдейтить запись, для кого было отправлено сообщение.десять раз спросить?
Зачем это нужно?
Пометить что для данного пользователя определенный текст был отправлен и не отправлять в следующий раз.

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