Как пофиксить дедлоки и таймауты во время транзакций сохранения данных в базу при многопоточности от ForkJoinPool?

Question

[DJFRX]

У меня есть поисковый движок по локальным сайтам. У меня есть LemmaService, который вполняет функции сохранения лемм в базу данных. Однако, сохранение в методе saveLemmasAndIndexes выполняется около 300 секунд при сохранении лишь 2000 сущностей за раз. Такого быть не должно. + Часто пишутся ошибки-дедлоки, например: 2024-04-28 18:26:38 ERROR jdbc.batch:293 - HHH100501: Exception executing batch [java.sql.BatchUpdateException: Deadlock found when trying to get lock; try restarting transaction], SQL: update lemma set frequency=?,lemma=?,site_id=? where id=?
Я вызываю метод getAndSaveLemmasAndIndexes вызывается из ForkJoinPool после сохранения страниц
Вы можете посмотреть исходный код LemmaService здесь: https://pastebin.com/dZ4zcWcp
Так же посмотрите https://pastebin.com/diQSPpw0 - это рекурсивный сайт, расширяющий RecursiveAction, откуда вызывается getAndSaveLemmasAndIndexes (он является точкой входа в LemmaService)
Так же вам может помочь структура базы данных MySql: https://pastebin.com/N7sT8kbU.
Так же хочу уточнить, что скорость сохранения других сущностей вполне нормальная и дедлоки отсутствуют
Буду безумно благодарен за помощь, уже больше недели вожусь с этим

Comments

[psiklop]

дедлоки неприятная штука, изучи как они случаются. я тоже давно боролся, но уже подзабыл. Назначь как минимум id индексным ключом или первичным и делай update where только по нему и в крайнем случае можно делать блокировку записи перед взаимодействием с таблицей или отлавливать исключение и повторять, как-то так я решал.

Answer 1

[Dmitry Roo]

Попробуйте отказаться от апдейтов. Это и быстрее и безопаснее.

Comments

[DJFRX]

А что делать, если мне обязательно знать актуальную частоту лемм? Без этого поисковая система будет работать некорректно. Что можно сделать?

[Dmitry Roo]

DJFRX, инсерты только использовать. Возможно, потребуется номер версии ещё добавить, но может и одного id хватит.
Старые, ненужные записи (если такие есть) можно удалять в фоновом режиме и/или по расписанию.

[DJFRX]

Dmitry Roo, я сделал такой механизм, дедлоки прошли, однако скорость все равно может достигать порядка 150_000МС, даже при объемах данных около 500 сущностей. почему может быть настолько неэффективная скорость?

[DJFRX]

я про скорость сохранения сущностей в методе saveLemmasAndIndexes

[Dmitry Roo]

DJFRX, у вас innoDB?

[DJFRX]

Dmitry Roo, да

[DJFRX]

Здравствуйте, проблема со скоростью была обсуловлена тем, что у меня стоял в MySql параметр auto commit на 1, я его отключил и теперь скорость отличная. Я очень благодарен вам за поддержку!

[Dmitry Roo]

DJFRX, у меня была какая-то такая гипотеза тоже, но за день не дошли руки дописать))