Программирование[9]

И это ведь только 2 апреля поцаны. Итого +10 лямов безработных за 2 недели у них.

Ramil написал 3 часа назад:

нид хелп

есть в даошке метод

void save (Huy huy) {

    ...

    if (huy.id != null) {

        mapper.setStatus(huy.id, Status.OBSOLETE)

    }

    ...

    mapper.insert(huy);

}

 

т.е. если хуй уже есть, то ставим ему статус OBSOLETE и инсертим новый хуй со статусом ACTIVE

так вот, если дохуя кто сохраняет, то бывает (редко), что 2 хуя появляются со статусом ACTIVE

как исключить такую ситуацию?

java 8

postgres 11

mybatis

 

 

ты чет многовато из кода вырезал похоже, тк выглядит он как хуйня, тк ты без else вставляешь в базу существующий объект

но допустим предположим, что всё там работает ок, но это и не важно, тк проблема на лвл выше

твои два потока не знают, что хуй уже существует и оба пытаются вставить новый

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

@Just.Doit

монолит, без параллельных

такое происходит когда с фронта одновременно приходят дохуя запросов на сохранение (id приходит с фронта)

@Kant

там id не уникальный (чтобы можно было проследить историю изменений хуя)

Kant написал 50 минут назад:

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

вот с этого места поподробнее, как это делается? я прост тупой джун

Так, а как ты тогда определяешь что хуй несколько раз добавляется, если у тебя нет возможность определить его уникальность?

тоже не понял

ты вычислил два активных хуя каким-то способом

только ни твой код, ни база не знают об этом. Им надо объяснить

Ramil написал 24 минуты назад:

@Just.Doit

монолит, без параллельных

такое происходит когда с фронта одновременно приходят дохуя запросов на сохранение (id приходит с фронта)

@Kant

там id не уникальный (чтобы можно было проследить историю изменений хуя)

Kant написал 1 час назад:

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

вот с этого места поподробнее, как это делается? я прост тупой джун

uniq constaint на кортеж id+status

короч id это рандомным uuid (генерится постгресом при создании)

с фронта прилетает хуй с определенным uuid

находим в базе старый хуй с этим uuid, меняем ему статус и инсертим новый хуй с этим же uuid

если много хуев одновременно прилетает, то есть шанс, что между сменой статуса и инсертом заинсертится такой же хуй

ну я так думаю, по крайней мере

Just.Doit написал 24 минуты назад:

Ramil написал 49 минут назад:

@Just.Doit

монолит, без параллельных

такое происходит когда с фронта одновременно приходят дохуя запросов на сохранение (id приходит с фронта)

@Kant

там id не уникальный (чтобы можно было проследить историю изменений хуя)

Kant написал 1 час назад:

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

вот с этого места поподробнее, как это делается? я прост тупой джун

uniq constaint на кортеж id+status

если есть кейс что должны быть не уникальные кортежи, а при этом только для id+ACTIVE должно быть уникальным - то можно добавить версию, повесить уникальность на кортеж id+status+version , возможно также есть смысл делать оптимистик лок на апдейт

итого делаешь фильрованный индекс в базе для начала

гугл говорит, что пострес в них умеет, итого что-то типа

create unique index ix_uniq_hui on hui_table(uuid, status) where (status = 'active')

если устраивает, что база пошлет при вставке и фронту выдается сообщение, что что-то пошло не так, попробуй еще раз, то достаточно в коде исключение ловить и сообщение фронту отсылать

если это логически неправильно, то всё зависит от твоего кода

условно ситуация должна выглядеть как

1. оба потока читают строчку с гуидом из базы, получают один и тот же id

2. оба потока обновляют строчку на статус obsolete (второй просто вхолостую)

3. оба потока ебашут новую строчку в базу

без уникального индекса всё работает без падений, с ним сдохнет на пункте 3 опоздавший поток

если юзаются транзакции (надеюсь), то прикручивается доп колонка версии для optimistic concurrency, которая пошлет второй поток еще на пункте 2, сказав, что ты чел опоздал, кто-то уже обновил строку с тех пор, как ты ее читал. Может ли твоя ормка в него хуй знает, если делать это руками проще сдохнуть

вообще данное свойство называется идемпотентность - тебе не важно количество идентичных запросов с фронта, а также степень их параллелизма и интеснивности если запросы идемпотентны

паттерны идемпотентности можешь нагуглить сам

Kant написал 2 минуты назад:

итого делаешь фильрованный индекс в базе для начала

гугл говорит, что пострес в них умеет, итого что-то типа

create unique index ix_uniq_hui on hui_table(uuid, status) where (status = 'active')

 

 

ох ты ж нихуя себе, даже такое есть

Kant написал 2 минуты назад:

если делать это руками проще сдохнуть

лол что

5 строк кода

а хотя если там орм очень умная и код написан таким образом что на эту умность рассчитывает - то наверное да, в общем виде будет сложно (но ничто не мешает закостылить)

вообще надо сделать так чтобы второй поток тоже все сохранял

может тогда как-то можно сделать чтоб создавался только 1 поток и была очередь на сохранение хуя, так можно сделать?

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

И вообще, у тебя получается текущий стейт + лог в одной таблице чтоли? Лучше нинада так, неудобно по моему опыту это.

Ramil написал 24 минуты назад:

вообще надо сделать так чтобы второй поток тоже все сохранял

может тогда как-то можно сделать чтоб создавался только 1 поток и была очередь на сохранение хуя, так можно сделать?

можно

GoldRobot написал 19 минут назад:

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

проблема не в апдейте

а в дабл инсерте

в транзакциях это кажется только через serializable фиксится (но я уже не помню все эти уровни, могу ошибаться)

Ramil написал 24 минуты назад:

вообще надо сделать так чтобы второй поток тоже все сохранял

может тогда как-то можно сделать чтоб создавался только 1 поток и была очередь на сохранение хуя, так можно сделать?

я кажется понял

мне кажется тебе должна помочь явная версионность. ты делаешь селект в бд по id+ACTIVE. тебе помимо всего прочего приходит версия. ты делаешь update id,ACTIVE,version в новое значение, потом делаешь инсерт id,ACTIVE,{version+1}. чтобы не было х2 инсерта вешаешь уникальность на id+version

насчет 1го потока и очереди есть опасения, хотя сформулировать я их не могу, просто интуитивно

Бля какой же кайф работать в компании над внутренним продуктом, а не быть аутсорсным мясом в аренде у пендосов. Речь, понятно, про Украину, у москалей вроде и так нормально с этим.

Just.Doit написал 5 минут назад:

проблема не в апдейте

а в дабл инсерте

в транзакциях это кажется только через serializable фиксится (но я уже не помню все эти уровни, могу ошибаться)

В постресе read commited по дефолту тразакции

Тоесть, вот есть у тебя 2 запроса (апдейт+инсерт)

Идет одновременный запрос, апдейт строки Х, вставить У

Первая транзакция успела первой, она апдейтит Х и вставляет Y

Вторая транзакция вторая, она ждет пока первая тразакция выполнится (заапдейтит и вставит), и только потом начнет апдейтить, а значит попадет на строку которую вставила первая транзакция

кстати по однопотоку - нам нужен 1поточность для 1го id 

можно параллелить как угодно если сделать партицирование по id (берется хеш от id и делим на количество очередей, берем остаток от деления и направляем на очередь с данным номером - тогда всегда все запросы по 1 id придут на 1 очередь)

это кстати очень похоже на задачу которую удобно решать акторами (Akka) 

GoldRobot написал 8 минут назад:

Just.Doit написал 15 минут назад:

проблема не в апдейте

а в дабл инсерте

в транзакциях это кажется только через serializable фиксится (но я уже не помню все эти уровни, могу ошибаться)

В постресе read commited по дефолту тразакции

 

Тоесть, вот есть у тебя 2 запроса (апдейт+инсерт)

Идет одновременный запрос, апдейт строки Х, вставить У

Первая транзакция успела первой, она апдейтит Х и вставляет Y

Вторая транзакция вторая, она ждет пока первая тразакция выполнится (заапдейтит и вставит), и только потом начнет апдейтить, а значит попадет на строку которую вставила первая транзакция

помоему ты путаешь

уровни изоляции не говорят про блокировки между апдейтами

уровни изоляции вообще про чтение (которого у нас тут вообще не происходит, лол)

нужно смотреть конкретные блокировки в постгресе по апдейтам, инсертам и их свзяь с транзакциями

Блокировка тоже по дефолту идет

Я к слову вообще не уверен можно ли менять это глобально сразу на всех транзакциях к базе, а не только изнутри транзакции локально

Инсерт, селект не блочится

moonfangtopich написал 13 минут назад:

Бля какой же кайф работать в компании над внутренним продуктом, а не быть аутсорсным мясом в аренде у пендосов. Речь, понятно, про Украину, у москалей вроде и так нормально с этим.

Куда ты устроился?

БТВ какой же кайф на плюсах писать как белый человек. Все понятно, удобно, просто. А не весь этот рак интерпретируемых языков с динамической типизацией.

GoldRobot написал 21 минуту назад:

Just.Doit написал 28 минут назад:

проблема не в апдейте

а в дабл инсерте

в транзакциях это кажется только через serializable фиксится (но я уже не помню все эти уровни, могу ошибаться)

В постресе read commited по дефолту тразакции

 

Тоесть, вот есть у тебя 2 запроса (апдейт+инсерт)

Идет одновременный запрос, апдейт строки Х, вставить У

Первая транзакция успела первой, она апдейтит Х и вставляет Y

Вторая транзакция вторая, она ждет пока первая тразакция выполнится (заапдейтит и вставит), и только потом начнет апдейтить, а значит попадет на строку которую вставила первая транзакция

вторая транзакция залочится после чтения строки и узнавания айдишки, которую она обновлять собралась

да, она подождет коммита первой, сходит в базу, ебнет туда поверх еще раз обсолет, который там и был, и ничего ей не помешает

для избежания такого надо принудительно лочить в таком случае еще и при селекте в этой же транзакции (у постгре есть для этого классный select for update, но я сомневаюсь, что ормка его вызывает)