Постоянные коннекты к БД и мультипоточность

zuxel

Новичок
Делаю мультипоточную обработку данных из БД, чтобы работали ручные блокировки строк приходится работать в постоянным соединениям, но при работе из разных потоков постоянно возникают ошибки из-за чего соединение падает и, естественно, все ломается. Есть ли возможность создавать несколько постоянных соединений или как корректно организовать работу, чтобы потоки могли корректно использовать единое соединение?
 

Redjik

Джедай-мастер
статья на хабре была что ли? второй раз за неделю этот бред слышу...
ты себе представляешь оверхед форка?
 

AnrDaemon

Продвинутый новичок
Ты из его мыслеизвержения чего-нибудь понял?
Я только понял, что он, не выяснив, что именно происходит, бросился это нечто лечить.
 

Redjik

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

WMix

герр M:)ller
Партнер клуба
ну те открыта 1 консоль базы данных, и параллельно 10 человек в ней работают?
 

zuxel

Новичок
ну те открыта 1 консоль базы данных, и параллельно 10 человек в ней работают?
ну можно и так сказать, только люди - это форки процесса, у которых не получается нормально работать с предварительно установленным в материнском процессе persistent connection, соединение падает с разными ошибками, как корректно пошарить это соединение на все форки?
 

zuxel

Новичок
как тогда организовать мультипотоковую обработку данных, блокируя обрабатываемые строки на уровне бд (в моем случае это pgsql и
pg_try_advisory_lock())?
 

WMix

герр M:)ller
Партнер клуба
люди выстроются в очередь (сериализируют последовательность), и будут работать поочереди. а то может и легко SuEpLdEaCtTe в базу придти.
а в случае если одному из них нужна транзакция, все будут ждать от begin до commit
консоль не видит кто печатает, договориться придется им самим
 
Последнее редактирование:

MiksIr

miksir@home:~$
У каждого форка своя сессия (соединение). pg_try_advisory_lock как раз и предназначен для работы между сессиями.
 

WMix

герр M:)ller
Партнер клуба
мне кажется зависит от того что произошло вначале, форк или соединение
 

MiksIr

miksir@home:~$
Ну форк должен быть сначала, это факт. Причем тут постоянные соединения вообще не особо нужны. Да они и вообще не особо нужны ;)
 

WMix

герр M:)ller
Партнер клуба
тут сразу вспоминается последовательность комманд: зайти, приспустить штаны, сесть, расслабиться. если последовательность поменять результат может быть неожиданный
 

zuxel

Новичок
У каждого форка своя сессия (соединение). pg_try_advisory_lock как раз и предназначен для работы между сессиями.
Дока говорит что блокировка сохраняется в рамках текущего соединения и освобождается только при ручном снятии или падении соединения, если выбрать строки с их блокированием, обработать и потом сделать апдейт, ко времени апдейта бловировки не будет - она упадет после завершения первого селекта. Поэтому и нужное перманентное соединение
 

zuxel

Новичок
люди выстроются в очередь (сериализируют последовательность), и будут работать поочереди. а то может и легко SuEpLdEaCtTe в базу придти.
а в случае если одному из них нужна транзакция, все будут ждать от begin до commit
консоль не видит кто печатает, договориться придется им самим
По очереди не надо, надо параллельно, чтобы быстрее выполнить тяжелую операцию
И договариваться здесь не надо будет, вместо этого бд будет отдавать только те строки, что еще не были выбраны для обработки
 

AnrDaemon

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

zuxel

Новичок
Да, я знаю. А ты знаешь как сделать, чтобы в одном запросе выбрать строки, потом в php их обработать и записать результат, и все это в рамках одного _не_постоянного_ соединения?
 
Сверху