я щас его код посмотрел. ум... sub is_disconnect_sybase ...  и остальные — серьёзно? понимаю, что Коля старый, ему 14 лет, но как на счёт fork safe?

устройство "перехвата" запросов довольно простое, не вижу предусмотра вложенных ->txn_do. "а вы так не делайте" — аргумент, но модуляризация кода порой к такому приводит.

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

Замечатальная штука, но я отсюда о ней и узнал :)

Хотя в AnyEvent::MySQL тоже логика реконнектов встроена прямо

Олег тут чуть выше. Ему и спасибо.

В общем всё понятно. Полностью нормальных способов отловить протухлость соединения с mysql нету. Есть какой-то DBIx, которого хоть и похваливают, но тут же сами же и договаривают сразу же на всякий случай про то, что и он (даже он!) не лишён недостатков. Эх...
Получается так, почти  равнозначно - что готовые модули использовать, что самому контроль протухлости ваять.

На счёт "самому ваять":

Была у меня когда-то мысль - сравнивать время жизни моего соединения перл-mysql с времением работы сервера mysql:

mysql> SHOW GLOBAL STATUS LIKE 'Uptime';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Uptime        | 3759  |
+---------------+-------+
1 row in set (0,00 sec)

[а как тут в телеге, кстати, делать, чтобы код не ехал?]

Ну эта идея хоть и интересна, но она даёт только ответ на вопрос - а не перезапустил ли кто-нибудь сервер mysql после того, как я открыл соединение с ним.
Но соединение ж может отвалиться и с неперезапускавшимся сервером.
Тогда надо делать другие проверки.
Ну чтение данных из заведомо непустой таблицы проверять легко - если ответ пуст, значит дело - уже труба и это хорошо.
Но как проверять результат работы команд INSERT да UPDATE? Контрольным считыванием информации, которая изменилась в таблице после таких команд? Во была халва... Эх...

Что происходит с dbh при выполнении crud и сдохшей субд?

Зачем тебе все это знать? Даже если сервер перезагрузился в процессе работы - что с того? Если приложение умеет работать с потерей коннекта, то оно просто дольет данные когда сервер поднимется.

++

Не коля, а модулю 14 лет. Но базу рестартить можно без отвала. Ну рамблер, мейл.ру и другие проработали на нем под огромной нагрузкой эти годы, и проблем с форками не наблюдалось. Не спорю что конектор шире и лучше, там десяток человек работали над ним в составе DBIC (особенно если еще научить его переживать рестарты), но и этот норм справляется с описанной проблемой

Приложению должно быть фиолетово на то, что там с сервером. Ему куда важнее быть уверенным, что транзакция вкоммичена

А вот пинг не помогает ничем, кроме как нагрузку увеличивает

"hijacked" — просто продолбали оплату. whois perl.com показывает "Registry Expiry Date: 2031-01-26T15:26:42Z"

Эпик вин ((

> Получается так, почти  равнозначно - что готовые модули использовать, что самому контроль протухлости ваять.

это какое-то выборочное чтение. то есть цели решить проблему не было, была цель завести тему, судя по всему.

инвалидируется

0.10  2009-10-05T21:16:03
      - Initial version, with code borrowed from DBIx::Class, Apache::DBI,
        Catalyst::Model::DBI, and various other locales.

ну, этот помоложе будет, ему 11+ лет. но за него в своё время очень Рэндэл Шварц агитировал, откуда я про него и узнал.