AP
Короче, дбикс-коннектор наш друг
Size: a a a
2020 September 01
AP
во-вторых там и без того секса будет, особенно с лялихом.
Локинг он всегда такой.
VO
локинг тут только усугубляет
AP
Если коротко - суть протокола TCP (одна из) - в том, чтобы скрывать проблемы соединения от вышестоящего уровня (утрирую несколько, конечно). Соответственно, о том, что проблема с соединением есть, можно узнать далеко не сразу. А если у клиента и сервера разные настройки по таймауту соединения, один из них может думать что соединение разорвано, а другой - ещё пытаться дождаться отправки запроса или результата его выполнения.
Разве в этом суть? Ну да ладно, я не готов с телефона спорить
IA
Разве в этом суть? Ну да ладно, я не готов с телефона спорить
Это просто достаточно трудноопределяемая и редкая проблема. Если не в больших масштабах, то можно и вообще не встретиться ни разу. )
IA
Конечно, есть и другие. Но мне кажется, что они проще.
VO
в общем да, о том что соединение разорванно можено не узнать до тех пор пока что-то не пошлешь.
VG
для этого и придумали пинги по таймеру
VO
так между пингами ничего не меняется.
DE
кто нибудь помнит что значит "the sigil bits" ?
IA
Не уверен, кажется обозначение в таблице символов о том, какого типа переменная (в смысле, как к ней обращаться). Но возможно я что-то с чем-то путаю.
AP
Denis Erygin
вместо $dbh->ping дернуть "SELECT now()"
1) это скл-выражение, которое надо будет распарсить, построить байт-код на выполнение, исполнить;
2) ты предлагаешь ещё и вызов с ненулевой стоимостью;
3) многие драйвера есть специализированный вызов "пинг", чтобы не нужно было левые скл-запросы делать.
2) ты предлагаешь ещё и вызов с ненулевой стоимостью;
3) многие драйвера есть специализированный вызов "пинг", чтобы не нужно было левые скл-запросы делать.
OP
Ни пинг ни чего либо еще не дают персистент конекшена. Это полная херня
OP
Он делается по другому. Надо просто послать запрос как обычно а если он наебнулся, посмотреть почему, и если от отвала то тогда перекрнекимтся и послать этот же запрос заново.
AP
Не очень-то хорошо оно работает. Иногда и совсем не работает. Но тут кроме того, чтобы делать $dbh->ping перед каждым запросом, в общем-то ничего и не посоветуешь. И даже тогда ещё придётся повозиться. TCP-соединение может быть разорвано, а может и нет. Причём обе стороны могут считать по-разному. Там ещё и околоядерных настроек вроде бы куча была.
пинг перед каждым запросом не обязательно. эту тему довольно изящно решает
DBIx::Connector, там можно fixup режим использовать, когда обломы изза пропавшего "внезапно" соединения можно запустить повторно после восстановленияя соединения. я развивал тему дальше, делая повторы пока не восстановится соединение — мне было полезно: когда админ внезапно апгрейдыл постгрес, сайт просто замирал вместе со всеми запланированными запросами/транзакциями и затем продолжал работать без потери данныхOP
А если транзакция то все запросы сеачала заново
OP
DBIx::RetryOverDisconnects как пример модуля который это прозрачно делает.
AP
А если транзакция то все запросы сеачала заново
бегин-ворк (транза) енд-ворк. если транза обломалась, то бд сама откатит состояние и можно повторить всю транзу. у дбикс-коннектора запросы оформляются как субрутины, поэтому повтор легко сделать
OP
Да у модуля который я написал тоже самое
OP
При условии что ты транзакции оформляешь в сабы а не руками бегин ебашишь