Т.е. в принципе у нас любой update который меняет более одной строки в недетерминированном порядке может вызвать deadlock.
Я вот сейчас задумался почему я раньше с этим не сталкивался - думаю потому, что в большинстве приложений с которыми я раньше имел дело изменения были однострочными
Как лучше с таким бороться. Я подозреваю если вероятность не высокая, то навреное лучше всего фэйлить операцию в целом и пусть дальше механизм retry за нас доделывает. Потому, что массово писать код как это показано в статье - нет никакой возможности.
>Получается, сначала подходящие под условие строки были в "каком-то" порядке прочитаны, а уже после этого UPDATE стал их менять, накладывая блокировки в том самом порядке, в котором мы их физически прочитали с носителя.
ну прочитала БД строки в случайном порядке и меняет их одну за одной. Но блокировка то откуда?
Имеется ввиду, что соседняя транзакция читает ту же таблицу в другом порядке и блокирует строки одну за одной по другому? Т.е. транзакция А блокирует строки 1,2,3 а транзакция Б блокирует строки 2,1,3 и на блокировке строк 1 и 2 их и деллочит?
>Все именно так. Высокоскоростные кабели всегда стоят дорого.
Я как-то не знал про такой момент, а что там в нем такого дорогого? Золото вместо меди/мономолекулярная медь? Встроенный в провод чип (чип вообще-то должен быть дорогим)
Мне прям любопытно стало - что там в проводе так может стоить?
Там основная проблема была именно в "не трогай". Это прям длинная, грустная история. В комментариях ее так просто не рассказать.
Но в целом в современной индустрии есть большая проблема с проактивностью. Чуваков готовых 8 часов на работе клепать формочки по шаблону не задумываясь о том как оно работает "работает не трожь" - на порядки больше тех кто понимает как оно работает или готовых разобраться в этом. Поэтому я привествую любое проявление любопытства - с этим гораздо проще справлятся и менеджить, чем с безволием и апатией.
Блин, ну так и вся часть "Подводя итог" тоже гипербола :-)
>Поэтому я бы лично сказал что "If it works, don't touch it" правило скорее полезное чем вредное.
Может быть у нас просто субъективный опыт разный. Я видел ситуации когда несколько команд из 8+ человек годами вращались вокруг гигантских монолитив в парадигме "не будем трогать потому, что не понимаем и понимать не хотим, но чтобы решить задачу - напостылим тут сбоку ад и треш"
Способность команды менять продукт в любом произвольном месте, если потребуется, для меня заметно важнее страховки от дятла.
Как с дятлом справиться с знаю и умею, а вот как справится с группой из 20 типа разработчиков которые годами пишут код, используя для этого спинной мозг вместо головного - я не знаю.
UPD - сори - много опечаток - меня уже работой затигивает, голова не о том думает
Тут дело не в аджайле как таковом. Точнее не в процессной его части.
Просто ритирика `вас наняли "клепать формочки"` она прям токсичная и сильно противоречит тому как сейчас принято строить команды. Да так тоже можно - особенно этим грешит кондовый советский (и как это не парадоксально кондовый американский) менеджмент.
Так тоже можно работать, не очень эффективно и очень не гибко. Но человечество придумал более эффективные способы организации команд. Основная проблема такого линейго военно-квадратно-гнездового подхода - это дыры в построении систем. Если начальник чего-то не знает или не предусмотрел, то как на видео - все обрушится от случайно зашедшего чувака.
Оба полярных подхода имеют плюсы и минусы, но это тема для отельной статьи
И даже в аджайле вещи вроде "улучшения кода" выходящие за рамки актуальной задачи стоит как минимум обсудить с командой. А не просто брать и улучшать втихаря.
я как раз и говорю что в данном случае улучшения втихаря спокойно тормознулись бы на этапе ревью PR
Спасибо!
Библиотека которая в ТОЧНОСТИ решает задачу называется Java Collections и уже идет в JRE в пакете java.util.
Там оба решения в одну строку. Ну еще dto класс создать если делать красиво
Собственно вопрос на уверенное понимание работы со структурами данных в Java. Условно говоря второй курс универа.
Без понимания этого народ начинает городить ужасное вплоть до того что "эту задачу нельзя решать в памяти, нужен NoSQL"
того, что написано 100% уже хватает :-) Как раз "готовое решение у ребят типа Apache Common" - это уже в минус
Ну тут есть два момента
Я знаю проект где уже который год прод на compose и это в общем норм
В доке compose написано, что в прод не берите и для большинства задкачиков предлагать что-то что противоречит тому что написано в доке - плохая идея.
Я бы сказал Devops в его текущем состоянии.
Хотел купить, засвидетельствовать почтение, но придется ждать, когда появится на Стиме.
Т.е. в принципе у нас любой update который меняет более одной строки в недетерминированном порядке может вызвать deadlock.
Я вот сейчас задумался почему я раньше с этим не сталкивался - думаю потому, что в большинстве приложений с которыми я раньше имел дело изменения были однострочными
Как лучше с таким бороться. Я подозреваю если вероятность не высокая, то навреное лучше всего фэйлить операцию в целом и пусть дальше механизм retry за нас доделывает. Потому, что массово писать код как это показано в статье - нет никакой возможности.
Каюсь, не понял, почему возникает блокировка.
>Получается, сначала подходящие под условие строки были в "каком-то" порядке прочитаны, а уже после этого
UPDATEстал их менять, накладывая блокировки в том самом порядке, в котором мы их физически прочитали с носителя.ну прочитала БД строки в случайном порядке и меняет их одну за одной. Но блокировка то откуда?
Имеется ввиду, что соседняя транзакция читает ту же таблицу в другом порядке и блокирует строки одну за одной по другому? Т.е. транзакция А блокирует строки 1,2,3 а транзакция Б блокирует строки 2,1,3 и на блокировке строк 1 и 2 их и деллочит?
Я правильно понял или тут в другом дело?
>Все именно так. Высокоскоростные кабели всегда стоят дорого.
Я как-то не знал про такой момент, а что там в нем такого дорогого? Золото вместо меди/мономолекулярная медь? Встроенный в провод чип (чип вообще-то должен быть дорогим)
Мне прям любопытно стало - что там в проводе так может стоить?
Ну я тут имел ввиду, что новая спека позволит обойти минусы
Надеюсь наступит момент, когда можно будет воткнуть монитор в USB-C - в него другой монитор, в другой монитор калвиатуру, мышь и гарнитуру.
А в клавиатуру третий монитор. И все будет бесшовно работать.
Ну начальство в больших корпорациях это отдельная история.
Там основная проблема была именно в "не трогай". Это прям длинная, грустная история. В комментариях ее так просто не рассказать.
Но в целом в современной индустрии есть большая проблема с проактивностью. Чуваков готовых 8 часов на работе клепать формочки по шаблону не задумываясь о том как оно работает "работает не трожь" - на порядки больше тех кто понимает как оно работает или готовых разобраться в этом. Поэтому я привествую любое проявление любопытства - с этим гораздо проще справлятся и менеджить, чем с безволием и апатией.
Блин, ну так и вся часть "Подводя итог" тоже гипербола :-)
>Поэтому я бы лично сказал что "If it works, don't touch it" правило скорее полезное чем вредное.
Может быть у нас просто субъективный опыт разный. Я видел ситуации когда несколько команд из 8+ человек годами вращались вокруг гигантских монолитив в парадигме "не будем трогать потому, что не понимаем и понимать не хотим, но чтобы решить задачу - напостылим тут сбоку ад и треш"
Способность команды менять продукт в любом произвольном месте, если потребуется, для меня заметно важнее страховки от дятла.
Как с дятлом справиться с знаю и умею, а вот как справится с группой из 20 типа разработчиков которые годами пишут код, используя для этого спинной мозг вместо головного - я не знаю.
UPD - сори - много опечаток - меня уже работой затигивает, голова не о том думает
Вообще забавное совпадение, я как раз в сентябре в одну контору собеседовался, у них как раз начальник такой квадратно гнездовой.
И потом мне коллеги за чашкой чая про проблемы конторы рассказывали - так оно прям идеально по учебнику совпало "симптомы - проблемы".
Но времени слишком мало прошло, эту историю рассказывать еще нельзя :-)
Тут дело не в аджайле как таковом. Точнее не в процессной его части.
Просто ритирика `вас наняли "клепать формочки"` она прям токсичная и сильно противоречит тому как сейчас принято строить команды. Да так тоже можно - особенно этим грешит кондовый советский (и как это не парадоксально кондовый американский) менеджмент.
Так тоже можно работать, не очень эффективно и очень не гибко. Но человечество придумал более эффективные способы организации команд. Основная проблема такого линейго военно-квадратно-гнездового подхода - это дыры в построении систем. Если начальник чего-то не знает или не предусмотрел, то как на видео - все обрушится от случайно зашедшего чувака.
Оба полярных подхода имеют плюсы и минусы, но это тема для отельной статьи
я как раз и говорю что в данном случае улучшения втихаря спокойно тормознулись бы на этапе ревью PR
>А если вас наняли "клепать формочки", то в такой ситуации не особо хорошая идея "улучшать" вещи, которые вас не просили улучшать
Это довольно сильно противоречит современным понятиям о том как должна работать команда. Прям начиная с Agile Manifesto и далее пол best practices.
Но как я сказал если работа проекта устроена по лекалам конца 20-го века, то да. Но тут уже надо решать с кем вам больше по пути
Дома два Synology - из коробки закрывает все вопросы с облаком. Тихий.
Интересно, бывает так, что печень меняет больше одного хоязина?
покрытие с магнитной пленки имеет свойство "осыпаться"