Камень в MySQL

Давно хотел полить ядом реализацию MVCC в замечательном MySQL (и MariaDB с XtraDB тоже):

mysql  Ver 14.14 Distrib 5.5.15

tx-A> CREATE TABLE make_deadlock (id int PRIMARY KEY,
                                  sid int,
                                  num int,
                                  INDEX (num)
                                 ) ENGINE=INNODB;
tx-A> INSERT INTO make_deadlock VALUES (1, 1, 1);

-- Поехали!
tx-A> BEGIN;
tx-B> BEGIN;
tx-A> UPDATE make_deadlock SET num = num + 1 WHERE id = 1;
tx-B> UPDATE make_deadlock SET num = num + 1 WHERE sid = 1;
-- Транзакция B ожидает A, понятное дело.
tx-A> UPDATE make_deadlock SET num = num + 1 WHERE sid = 1;
tx-B> ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
-- WTF?!

Две транзакции не поделили одну строчку, какая прелесть. Причина, конечно, простая — в этой гениальной реализации MVCC лочатся не строки, а индексы — но больше похоже, что Монти держит нас за идиотов.

SQL и рекурсия

Довольно таки давно в PostgreSQL реализовали CTE.

Common Table Expression (CTE) — это временные результирующие наборы, определенные в области выполнения единичных инструкций SELECT, INSERT, UPDATE, DELETE. Проще говоря, это вьюха которая определяется на момент выполнения запроса.

Возможно, CTE покажется простой альтернативой вложенных запросов, но прелесть в том что CTE позволяет делать рекурсивные запросы.

Асинхронный HTTP прокси-сервер yup.

Недавно явил свету маленький демон yup. Написан он на ruby, разворачивается в два шага (gem install && run).
Назначение у него простое:

1. принять HTTP-запрос и сразу ответить клиенту,
2. запрос ставится в очередь и пересылается указанному в конфигурации yupd хосту,
3. если пересылка запроса постигла неудача (проблемы с сетью, глюки софта), то повторить через некоторое время.

Это можно изобразить диаграммой.
В итоге, получаем маленький модуль на который можно без особого труда делегировать гарантированную и асинхронную отправку HTTP-запросов на какой-либо HTTP-сервис.