Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > PostgreSQL > Выполнение функции без блокировки

Автор: woland 20.10.2011, 15:15

Хочу в цикле запускать функцию с разными параметрами, но чтобы запущенные функции работали параллельно, то есть не цикл не зависал, ожидая окончания выполнения каждой функции. Что-то типа запуска выполнения функций в разных потоках. Это реально в Postgresql 9? Как это можно осуществить?

Автор: LSD 20.10.2011, 16:21

Можно установить http://pgfoundry.org/projects/pljava/ (или любой другой язык с поддержкой потоков) и писать на нем. Тут правда есть одна тонкость: у них у всех будет одно соединение с базой. И если надо паралелить именно работу с базой, то ничего не выйдет.

Автор: woland 21.10.2011, 15:20

То есть выход один? Создавать кучу коннектов и запускать на выполнение функции каждую в своем соединении?

Автор: LSD 21.10.2011, 15:24

Да.

Автор: Zloxa 10.11.2011, 08:38

У ПГ нет своего, нативного жобшедулера?

Автор: LSD 10.11.2011, 13:47

Цитата(Zloxa @  10.11.2011,  09:38 ) У ПГ нет своего, нативного жобшедулера? Есть. Просто тут как-то не приняты оракловые извращения типа скедулить джоб на выполнение через секунду.

Автор: Zloxa 10.11.2011, 13:59

Зачем через секунду? Можно запланировать и "на вчера".  В чем извращенность подхода? Чем этот способ хуже разработки внешней приблудины?

Автор: LSD 10.11.2011, 19:04

Цитата(Zloxa @  10.11.2011,  14:59 ) В чем извращенность подхода? Использование инструмента не по назначению. Цитата(Zloxa @  10.11.2011,  14:59 ) Чем этот способ хуже разработки внешней приблудины? Над внешней приблудой больше контроля. Например изменения можно закоммитить только если все вычисления завершились успешно, а иначе откатить их. Потоки могут взаимодействовать между собой кешируя в памяти данные, передавая результаты и т.п.

Автор: Zloxa 10.11.2011, 20:31

Цитата(LSD @  10.11.2011,  19:04 ) Например изменения можно закоммитить только если все вычисления завершились успешно, а иначе откатить их Только что ж вроде говорилось, что у каждого птока своя сессия. Согласованно их все равно закомитить никак не удастя. Цитата(LSD @  10.11.2011,  19:04 ) Потоки могут взаимодействовать между собой кешируя в памяти данные, передавая результаты и т.п.  Так то ТС потоки нужны лишь чтоб уж написанную ХП дергать. Необходиомть интерпроцесс комьюникейшна им вроде не озвучивалась. Хотя и для этого, наверное в ПГ найдутся нативные средства. Или ты ему предлагаешь все взять и переписать? В соседнем топике, помню, тебе претил такой подход к решению проблем ТС.   Цитата(LSD @  10.11.2011,  19:04 ) Использование инструмента не по назначению. Т.е.Когда AQ поднимает жобы для перманетного пропагейта(не знаю емкого русского термина для этого процесса) очереди, это тоже, наверное не по назначению? И процедуру ведь те жобы одну запускают, по жобе на каждое направления пропагейшна. Мне кажется - очень похоже на исходящие от ТС постановку. Или когда десяток/другой жоб поднимают, чтоб промолотить одни данные, но каждую по своему хэш резалту - тоже не по назначению? ТС заявил лишь что ему надо запустить одну процедуру в нескольких потоках ассинхронно. И только. Жоба, при такой постановке - наиболее простое и очевидное решение - нет. Другое дело, если платформа не держит своих жоб. Я чет слышал какой то звон, мол жобшедулер там не интегрирован чтоли с платформой или чтото в том духе.

Автор: LSD 11.11.2011, 12:15

Цитата(Zloxa @  10.11.2011,  21:31 ) Только что ж вроде говорилось, что у каждого птока своя сессия. Согласованно их все равно закомитить никак не удастя. http://www.postgresql.org/docs/current/static/sql-prepare-transaction.html   Цитата(Zloxa @  10.11.2011,  21:31 ) Так то ТС потоки нужны лишь чтоб уж написанную ХП дергать. Необходиомть интерпроцесс комьюникейшна им вроде не озвучивалась. Хотя и для этого, наверное в ПГ найдутся нативные средства. Цитата(Zloxa @  10.11.2011,  21:31 ) Т.е.Когда AQ поднимает жобы для перманетного пропагейта(не знаю емкого русского термина для этого процесса) очереди, это тоже, наверное не по назначению? И процедуру ведь те жобы одну запускают, по жобе на каждое направления пропагейшна. Мне кажется - очень похоже на исходящие от ТС постановку. Или когда десяток/другой жоб поднимают, чтоб промолотить одни данные, но каждую по своему хэш резалту - тоже не по назначению? ТС заявил лишь что ему надо запустить одну процедуру в нескольких потоках ассинхронно. И только. Жоба, при такой постановке - наиболее простое и очевидное решение - нет. А я и не говорил, что в данном конкретном случае это наилучший подход (ты же спрашивал про постгрес в целом). Я говорил, что использование джобов для фонового выполнения задач это все "от бедности", а не потому что это такой хороший инструмент. Цитата(Zloxa @  10.11.2011,  21:31 ) Или ты ему предлагаешь все взять и переписать? В соседнем топике, помню, тебе претил такой подход к решению проблем ТС. Это твои личные фантазии, я не предлагал ничего переписывать.   Цитата(Zloxa @  10.11.2011,  21:31 ) Другое дело, если платформа не держит своих жоб. Я чет слышал какой то звон, мол жобшедулер там не интегрирован чтоли с платформой или чтото в том духе. Это отдельная библиотека, которую надо доустанавливать. Впрочем весь постгрес такой.

Автор: Zloxa 11.11.2011, 12:44

Цитата(LSD @  11.11.2011,  12:15 ) Two-phase commit  Крутотень   Спасибо. В оракле TPC тоже реализован, он используется в  распределенных транзакциях и прозрачен для программитса, механизм включается неявно. А явно, да в контексте одной датабазы, но разных сессий, вроде как его нельзя задействовать. По кр. мере мне способ не известен.  Это реально можно испльзовать? Ты пробовал? Смутило в нотах: Цитата PREPARE TRANSACTION is not intended for use in applications or interactive sessions. Its purpose is to allow an external transaction manager to perform atomic global transactions across multiple databases or other transactional resources. Unless you're writing a transaction manager, you probably shouldn't be using PREPARE TRANSACTION. "external transaction manager" в моем воспаленном мозгу вызывает ассоциации с чем то жудко страшным, низкоуровневым, а предостережение об использовании в приложениях эту ассоциацию прочно закрепляет. И упоминание контекста мультидатабазистости тут тоже настораживает как-то.

Автор: LSD 14.11.2011, 11:37

Цитата(Zloxa @  11.11.2011,  13:44 ) Это реально можно испльзовать? Ты пробовал? Не пробовал. Цитата(Zloxa @  11.11.2011,  13:44 ) "external transaction manager" в моем воспаленном мозгу вызывает ассоциации с чем то жудко страшным, низкоуровневым, а предостережение об использовании в приложениях эту ассоциацию прочно закрепляет. И упоминание контекста мультидатабазистости тут тоже настораживает как-то. "external transaction manager" - скорее всего речь идет о http://en.wikipedia.org/wiki/Java_Transaction_API или чем-то подобном.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)