Pull to refresh

Comments 11

А ты так, от скуки написал? Или решал бизнес-задачу? :)
Это бизнес-задача, меня ей долго пинал Алексей Рыбак из Badoo.com, писал для них. Я об этом пишу в блоге.
Можете пояснить, пожалуйста, в какой ситуации это может понадобиться?
В первую очередь этот патч добавляет поддержку детектора дедлоков в user level lockи, что полезно если они используются в любых нетривиальных сценариях.

А в остальном, думаю надо разбираться по ситуации, скорее всего это связано как-то с управлением задачами или очередями — когда нужно исключить возможность одновременной работы двух или более клиентов, выполнить какую-то нетривиальную синхронизацию.
Эх, вот бы ещё патчик, который бы позволял в одном запросе более одного раза обращаться к временной таблице…
Это большой будет патч, но можно сделать. Я делал что-то подобное в проекте foreign keys for all storage engines, в MariaDB сейчас на этот счёт что-то делается, насколько я знаю.
Эх, не могу плюсовать. А жаль!
Очень круто, спасибо.
Можешь объяснить, в какой ситуации может повиться дедлок — эти user lock'и же не участвуют в транзакциях, не привязаны ни к каким ресурсам — откуда дедлоки, если они еще и рекурсивны теперь?..
Дедлок был возможен всегда например вот в такой ситуации:

connection c1:
lock table t1 write;

connection c2:
select get_lock('test', 0)

connection c1:
select get_lock('test', 7200)

connection c2:
lock table t2 write;

Ну а теперь может быть такой дедлок:

connection c1:
select get_lock('test1', 0)

connection c2:
select get_lock('test2', 0)

connection c1:
select get_lock('test2', 7200)

connection c2:
select get_lock('test1', 7200)

Патч все такие дедлоки ловит, выдаёт ошибки. Точнее, ловит MDL, патч просто это всё использует.
Здесь точно разные таблицы?

(пример №1)

connection c1:
lock table t1 write;

connection c2:
lock table t2 write;

Опечатка, одна коненчо. Принцип понятен :)
Sign up to leave a comment.

Articles