Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
05.07.2017, 13:23
|
|||
---|---|---|---|
|
|||
Асинхронный запрос |
|||
#18+
Всем привет! Вопрос, как вызвать (например, из Java) pg-функцию (которая выполняется дооолго, например, час) и не ждать ее завершения? Если вызвать pg-функцию и тупо разорвать соединение, не будет commit`a и функция не завершится... ... |
|||
:
Нравится:
Не нравится:
|
|||
|
05.07.2017, 13:45
|
|||
---|---|---|---|
Асинхронный запрос |
|||
#18+
Bazzzиз Java ... не ждатьjava.lang.Thread ... |
|||
:
Нравится:
Не нравится:
|
|||
|
05.07.2017, 13:50
|
|||
---|---|---|---|
|
|||
Асинхронный запрос |
|||
#18+
p2.Bazzzиз Java ... не ждатьjava.lang.Thread Спасибо, но хочется чтобы Ява сказала Постгресу "работай" (делай апдейты/инсёрты/...) и забыла про Постгрес, а не создавала дополнительный поток (этих потоков может получиться оооочень много, да и ни к чему они, результат выполнения функции Яве не важен)! ... |
|||
:
Нравится:
Не нравится:
|
|||
|
05.07.2017, 15:57
|
|||
---|---|---|---|
Асинхронный запрос |
|||
#18+
Bazzz, Запустить в джобе ... |
|||
:
Нравится:
Не нравится:
|
|||
|
05.07.2017, 16:02
|
|||
---|---|---|---|
|
|||
Асинхронный запрос |
|||
#18+
Alex__kKBazzz, Запустить в джобе Идею с джобом отвергли сразу, фактически, он должен будет срабатывать каждую секунду! ... |
|||
:
Нравится:
Не нравится:
|
|||
|
05.07.2017, 16:04
|
|||
---|---|---|---|
|
|||
Асинхронный запрос |
|||
#18+
Alex__kKBazzz, Запустить в джобе Идею с джобом отвергли сразу, фактически, он должен будет срабатывать каждую секунду! Да, и инициатором должна быть Ява (это веб-сервис). ... |
|||
:
Нравится:
Не нравится:
|
|||
|
05.07.2017, 17:16
|
|||
---|---|---|---|
Асинхронный запрос |
|||
#18+
Bazzz, если вы не напираете на отпускание (некоего) соединения, а только на асинхронность запускаемых вами (вообще говоря в другом соединении) запросов, вы можете теребонькать асинхронно вызовы через дблинк. но там очень много тонкостей, как их теребонькать правильно, (надо таки всегда рано или поздно вычитывать ответы, перед тем как потеребонькать в том же соединении по новой). dblink_send_query https://www.postgresql.org/docs/current/static/contrib-dblink-is-busy.html https://www.postgresql.org/docs/current/static/contrib-dblink-get-result.html и т.п. плюсы -- из жабы у вас одно соединение, но всё оно занято контролем над любым количеством асинхронных соединений дблинка с субд на себя. для синхронной работы из жабы вам нужно другое(другие) соединения. но, уж лучше писать всё в одном месте, нет ? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.07.2017, 12:10
|
|||
---|---|---|---|
|
|||
Асинхронный запрос |
|||
#18+
qwwqBazzz, если вы не напираете на отпускание (некоего) соединения, а только на асинхронность запускаемых вами (вообще говоря в другом соединении) запросов, вы можете теребонькать асинхронно вызовы через дблинк. но там очень много тонкостей, как их теребонькать правильно, (надо таки всегда рано или поздно вычитывать ответы, перед тем как потеребонькать в том же соединении по новой). dblink_send_query https://www.postgresql.org/docs/current/static/contrib-dblink-is-busy.html https://www.postgresql.org/docs/current/static/contrib-dblink-get-result.html и т.п. плюсы -- из жабы у вас одно соединение, но всё оно занято контролем над любым количеством асинхронных соединений дблинка с субд на себя. для синхронной работы из жабы вам нужно другое(другие) соединения. но, уж лучше писать всё в одном месте, нет ? Ухххх, спасибо Вам за совет, я почитал, попробовал, НО это не очень хороший подход потому, что: 1. присутствует гемор с вычитыванием ответов (хотя у меня получилось рвать коннект сразу после запуска запроса и вроде ОК). 2. не очень удобно вызывать функции базы, т.к. dblink_send_query заточен под получение результата типа record. 3. dblink кэширует все коннекты и запросы на своей стороне, а значит, его использование это то же самое, что делать на стороне Явы несколько потоков. 3. фактически, асинхрон в dblink создает на каждый запрос ФИЗИЧЕСКИЙ коннект к базе (которых в Pg1.5 по умолчанию всего 100). Ну а то, что самые долгие операции в высоконагруженной системе (в которой пользователи вызывают сотни-тысячи запросов в секунду) это коннекты - все знают. Так что не стоит использовать этот функционал для взаимодействия с базой со стороны веб-сервисов! У меня задача, вызвав функцию базы из Ява-приложения, закрыть транзакцию и не отменить этим выполнение только что вызванной функции! В любом случае, огромное спасибо qwwq за совет, хороший опыт!!! ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.07.2017, 13:16
|
|||
---|---|---|---|
Асинхронный запрос |
|||
#18+
Bazzz3. фактически, асинхрон в dblink создает на каждый запрос ФИЗИЧЕСКИЙ коннект к базе (которых в Pg1.5 по умолчанию всего 100). Ну а то, что самые долгие операции в высоконагруженной системе (в которой пользователи вызывают сотни-тысячи запросов в секунду) это коннекты - все знают. Так что не стоит использовать этот функционал для взаимодействия с базой со стороны веб-сервисов!ваше блаблабла неверно. если вы откроете в вашем единственном контрольном соединении жабы несколько ИМЕНОВАННЫХ коннектов дблинка, и не будете их сами закрывать, у вас будет (в вашем контролирующем соединении) пул постоянно открытых дблинк--соединений. Конечно вам придется постоянно опрашивать их на из_бизи , и при освобождении -- еще и аккуратно гет_резалтить. Но т.к. вам результаты не нужны, все вызовы вы можете оформит как returns void хранимки, и геттенье будет однотипным. и всё -- через одно контролирующее соединение жабы, без долгих вызовов и ожиданий. понятно, что все то же самое вы можете делать в жабе. аккуратно и по полочкам. открыть пул соединений (например накидав их в вектор) из которого выбирать свободные, делать в них вызовы (в отдельных нитях), и , по возвращению любого ответа (кроме коннекш лост и т.п.) возвращать соединение в пул. ну и т.п. Но вы сами этого не хотите. BazzzУ меня задача, вызвав функцию базы из Ява-приложения, закрыть транзакцию и не отменить этим выполнение только что вызванной функции! вы , вызвав любой из асинхронных методов дблинка, закрываете транзакцию "контролирующего соединения", "закрыть" исполняемую (в соединении==процессе, открытом дблинк-ом) транзакцию вы не можете, она еще не закончена. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.07.2017, 14:04
|
|||
---|---|---|---|
|
|||
Асинхронный запрос |
|||
#18+
qwwqваше блаблабла неверно. если вы откроете в вашем единственном контрольном соединении жабы несколько ИМЕНОВАННЫХ коннектов дблинка, и не будете их сами закрывать, у вас будет (в вашем контролирующем соединении) пул постоянно открытых дблинк--соединений. Про то и речь. Код: plsql 1.
подтвердит. Вы согласны, что на веб-сервис могут постучаться больше 100 пользователей одновременно? Вы согласны, что на каждый стук пользователя придется вызывать Код: plsql 1.
? Ведь функция базы выполняется долго. Ну, а теперь, просто вызовите Код: plsql 1.
и при стандартных настройка pg вылетит ошибка Код: plsql 1. 2.
qwwqоформит как returns void хранимки, и геттенье будет однотипным. Странно, но при попытке получить результат вызванное функции с результатом типа void типа Код: plsql 1.
получаю Код: plsql 1.
qwwqНо вы сами этого не хотите. Не то, что не хочу, сейчас так и делается, но этих потоков многооооо и они в статусе wait вместо того, что занимать полезной нагрузкой... qwwqтранзакцию вы не можете, она еще не закончена. Конечно не могу, плохо выразился. Попробую еще раз переформулировать: я хотел бы получив обращение пользователя на веб-сервис Явы, кинуть notify Постгресу о том, что надо начать такую-то большую обработку, и забыть про Постгрес до следующего обращения пользователя. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.07.2017, 14:26
|
|||
---|---|---|---|
|
|||
Асинхронный запрос |
|||
#18+
BazzzПопробую еще раз переформулировать: я хотел бы получив обращение пользователя на веб-сервис Явы, кинуть notify Постгресу о том, что надо начать такую-то большую обработку, и забыть про Постгрес до следующего обращения пользователя. Это задача приложения и ваша головная боль. И никак не является задачей базы. -- Maxim Boguk dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.07.2017, 14:53
|
|||
---|---|---|---|
|
|||
Асинхронный запрос |
|||
#18+
> я хотел бы получив обращение пользователя на веб-сервис Явы, кинуть notify Постгресу о том, что надо начать такую-то большую обработку, и забыть про Постгрес до следующего обращения пользователя. вам может помочь очередь. если нужна "транзакционная" -- посмотрите на pgq фрейморк ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.07.2017, 15:40
|
|||
---|---|---|---|
Асинхронный запрос |
|||
#18+
Bazzzqwwqваше блаблабла неверно. если вы откроете в вашем единственном контрольном соединении жабы несколько ИМЕНОВАННЫХ коннектов дблинка, и не будете их сами закрывать, у вас будет (в вашем контролирующем соединении) пул постоянно открытых дблинк--соединений. Про то и речь. Код: plsql 1.
подтвердит. Вы согласны, что на веб-сервис могут постучаться больше 100 пользователей одновременно? ачотакова ? BazzzВы согласны, что на каждый стук пользователя придется вызывать Код: plsql 1.
? нет, конечно у вас есть ограничение на 100 соединений== 100 процессов постгреса == 100 процессов , в которых выполняются "функции, которые долго". вне этих процессов постгреса==соединений они ["функции, которые долго"] выполнятся НЕ могут, откуда мораль -- открываете 100 соединений в пуле, и запросы СВЕРХ этих 100 ставите в очередь . как её кодить -- дело ваше. хотите в жабском пуле. хотите -- в пуле соединений дблинка. но потерь на открытие новых соединений у вас не будет (только при падении ранее поднятых, если вы пул напишете правильно, с переподнятием покойников). в целом очередь делается так -- вы берете из массива свободных соединений одно и отправляете в него запрос. массив сокращаете. если брать неоткуда -- ждёте. если соединение освободилось (запрос выполнен) -- возвращаете его в ваш массив. можете сразу жабский нотифай послать, ессно (или как оно там, дай бог памяти). если в жабе все делаете Bazzzqwwqоформит как returns void хранимки, и геттенье будет однотипным. Странно ?????, но при попытке получить результат вызванное функции с результатом типа void типа Код: plsql 1. 2. 3. 4.
BazzzНе то, что не хочу, сейчас так и делается, но этих потоков многооооо и они в статусе wait вместо того, что занимать полезной нагрузкой... они и занимаются полезной нагрузкой -- ожидают освобождения процесса поцгресса, занятого транзакцией. В противном случае вам пришлось бы организовывать опрос освобождения соединений руками, в цыкле, как в случае с дблинковым пулом и асинхронными вызовами (если вы до этого дошли). ... |
|||
:
Нравится:
Не нравится:
|
|||
|
07.07.2017, 09:12
|
|||
---|---|---|---|
Асинхронный запрос |
|||
#18+
qwwq, а если прикрутить еще pgbouncer к dblink, то dblink работать будет еще быстрее, поскольку устраняется оверхед на установление соединений, я где-то даже презентацию подобного видел людей из постгрес про, где они приводят эти цифры. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
07.07.2017, 09:32
|
|||
---|---|---|---|
Асинхронный запрос |
|||
#18+
Alex__kKqwwq, а если прикрутить еще pgbouncer к dblink, то dblink работать будет еще быстрее, поскольку устраняется оверхед на установление соединений, я где-то даже презентацию подобного видел людей из постгрес про, где они приводят эти цифры.то придется работать с синхронными запросами. потому как иначе будет "смешались в кучу конилюди" -- придется слать гет_резалты везде, и обрабатывать ошибки посыла нового запроса в соединение, не вычитавшего ответ. нет ? (могу врать -- надо подумать/тестануть в транзакшн--моде). и ещё я немного люблю препареды -- для них пг_баунсеры не подходят, навскидку. нужен пул с одинакими именованными препаредами, как св-вами соединений. хотя если ,кроме моей приблуды, никто данного пула баунсера не делит -- кажеццо вытанцуется, ... |
|||
:
Нравится:
Не нравится:
|
|||
|
|
start [/forum/topic.php?fid=53&mobile=1&tid=1996385]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
36ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
others: | 323ms |
total: | 456ms |
0 / 0 |