СП
Правильно я понял, что в моём случае нужна блокировка SERIALIZABLE ?
Size: a a a
2020 June 23
AM
Правильно я понял, что в моём случае нужна блокировка SERIALIZABLE ?
Честно говоря не знаю никого кто бы использовал данный режим. Но да, возможно это то что вы ищете. Скажу так, что я не могу дать вам компетентный ответ на этот вопрос. Попробуйте узнать мнение @acromegale или @MasterZiv
СП
Честно говоря не знаю никого кто бы использовал данный режим. Но да, возможно это то что вы ищете. Скажу так, что я не могу дать вам компетентный ответ на этот вопрос. Попробуйте узнать мнение @acromegale или @MasterZiv
по сути это счётчик, который должен возвращать всегда значение на 1 больше.
AM
Всем привет!
Подскажите, пожалуйста, можно как-то вести лог, какой юзер и когда делал alter table? в бинлоге сам факт я вижу, а имя юзера нет
Подскажите, пожалуйста, можно как-то вести лог, какой юзер и когда делал alter table? в бинлоге сам факт я вижу, а имя юзера нет
Я не уверен, но возможно вам поможет включение general log https://dev.mysql.com/doc/refman/8.0/en/query-log.html
AP
Я не уверен, но возможно вам поможет включение general log https://dev.mysql.com/doc/refman/8.0/en/query-log.html
Спасибо, мне не совсем подходит, т.к. высокие нагрузки
AM
Спасибо, мне не совсем подходит, т.к. высокие нагрузки
Мне кажется только так это возможно узнать
AM
Можете писать в tmpfs и ротировать, тогда нагрузка будет меньше, или отдельный диск для этих логов
IZ
Добрый день!
Есть такая логика в коде: "считать значение из БД → изменить значение → записать значение в БД"
На сервере может случится так, что два запроса из браузера пойдут одновременно. Соответственно мне нужно, чтобы второй запрос ждал, пока первый запрос сделает считывание/изменение/запись в БД и только после этого считывал значение из БД для себя.
Таблица INNODB.
Правильно я понимаю, что мне нужно обернуть в транзакцию мою логику и использовать её с блокировкой SERIALIZABLE ?
Есть такая логика в коде: "считать значение из БД → изменить значение → записать значение в БД"
На сервере может случится так, что два запроса из браузера пойдут одновременно. Соответственно мне нужно, чтобы второй запрос ждал, пока первый запрос сделает считывание/изменение/запись в БД и только после этого считывал значение из БД для себя.
Таблица INNODB.
Правильно я понимаю, что мне нужно обернуть в транзакцию мою логику и использовать её с блокировкой SERIALIZABLE ?
Для так называемых Webр приложений такой сценарий работы равносилен самоубийству
IZ
Добрый день!
Есть такая логика в коде: "считать значение из БД → изменить значение → записать значение в БД"
На сервере может случится так, что два запроса из браузера пойдут одновременно. Соответственно мне нужно, чтобы второй запрос ждал, пока первый запрос сделает считывание/изменение/запись в БД и только после этого считывал значение из БД для себя.
Таблица INNODB.
Правильно я понимаю, что мне нужно обернуть в транзакцию мою логику и использовать её с блокировкой SERIALIZABLE ?
Есть такая логика в коде: "считать значение из БД → изменить значение → записать значение в БД"
На сервере может случится так, что два запроса из браузера пойдут одновременно. Соответственно мне нужно, чтобы второй запрос ждал, пока первый запрос сделает считывание/изменение/запись в БД и только после этого считывал значение из БД для себя.
Таблица INNODB.
Правильно я понимаю, что мне нужно обернуть в транзакцию мою логику и использовать её с блокировкой SERIALIZABLE ?
Ты даже не сможешь обернуть это в транзакцию
СП
Для так называемых Webр приложений такой сценарий работы равносилен самоубийству
Этот запрос редко происходит
IZ
Добрый день!
Есть такая логика в коде: "считать значение из БД → изменить значение → записать значение в БД"
На сервере может случится так, что два запроса из браузера пойдут одновременно. Соответственно мне нужно, чтобы второй запрос ждал, пока первый запрос сделает считывание/изменение/запись в БД и только после этого считывал значение из БД для себя.
Таблица INNODB.
Правильно я понимаю, что мне нужно обернуть в транзакцию мою логику и использовать её с блокировкой SERIALIZABLE ?
Есть такая логика в коде: "считать значение из БД → изменить значение → записать значение в БД"
На сервере может случится так, что два запроса из браузера пойдут одновременно. Соответственно мне нужно, чтобы второй запрос ждал, пока первый запрос сделает считывание/изменение/запись в БД и только после этого считывал значение из БД для себя.
Таблица INNODB.
Правильно я понимаю, что мне нужно обернуть в транзакцию мою логику и использовать её с блокировкой SERIALIZABLE ?
Тут надо применить скорее технику, называемую "оптимистическая блокировка с последующей проверкой конфликта"
IZ
Можно найти в сети почти наверняка
СП
погуглил... если я правильно понял, то задача решается с помощью select for update.
select for update - ставит блокировку
потом я делают update и блокировка сниамется
select for update - ставит блокировку
потом я делают update и блокировка сниамется
СП
Тут надо применить скорее технику, называемую "оптимистическая блокировка с последующей проверкой конфликта"
Почитал ещё... Вроде бы такой вот вариант правильный:
begin;
select id from uid where
update uid set id=4 where
commit;
Мы делаем обычную транзакцию, но в селекте используем FOR UPDATE.
Получается при запуске таких транзакций параллельно они будут ждать и выполняться по очередеи.
Правильно я понимаю?
begin;
select id from uid where
name="x" for update;update uid set id=4 where
name="x";commit;
Мы делаем обычную транзакцию, но в селекте используем FOR UPDATE.
Получается при запуске таких транзакций параллельно они будут ждать и выполняться по очередеи.
Правильно я понимаю?
IZ
Почитал ещё... Вроде бы такой вот вариант правильный:
begin;
select id from uid where
update uid set id=4 where
commit;
Мы делаем обычную транзакцию, но в селекте используем FOR UPDATE.
Получается при запуске таких транзакций параллельно они будут ждать и выполняться по очередеи.
Правильно я понимаю?
begin;
select id from uid where
name="x" for update;update uid set id=4 where
name="x";commit;
Мы делаем обычную транзакцию, но в селекте используем FOR UPDATE.
Получается при запуске таких транзакций параллельно они будут ждать и выполняться по очередеи.
Правильно я понимаю?
У получится скорее всего в Web делать multi statement transactions
СП
У получится скорее всего в Web делать multi statement transactions
НЕ получится?
ls
Всем привет!
Подскажите, пожалуйста, можно как-то вести лог, какой юзер и когда делал alter table? в бинлоге сам факт я вижу, а имя юзера нет
Подскажите, пожалуйста, можно как-то вести лог, какой юзер и когда делал alter table? в бинлоге сам факт я вижу, а имя юзера нет
audit plugin
ls
Почитал ещё... Вроде бы такой вот вариант правильный:
begin;
select id from uid where
update uid set id=4 where
commit;
Мы делаем обычную транзакцию, но в селекте используем FOR UPDATE.
Получается при запуске таких транзакций параллельно они будут ждать и выполняться по очередеи.
Правильно я понимаю?
begin;
select id from uid where
name="x" for update;update uid set id=4 where
name="x";commit;
Мы делаем обычную транзакцию, но в селекте используем FOR UPDATE.
Получается при запуске таких транзакций параллельно они будут ждать и выполняться по очередеи.
Правильно я понимаю?
да, это будет работать
СП
Спасибо
IZ
да, это будет работать
А connection pool?