16.4. Реализация#
16.4. Реализация
The autonomous session
выполняется в отдельном процессе. Основной процесс и autonomous session
обмениваются данными через стандартный протокол frontend/backend. Выполнение autonomous session
синхронное, основной процесс ждет сообщения Complete от autonomous session
. Сообщения отправляются через очереди общей памяти.
Автономный сеанс берется из пула автономных сеансов
. Для каждого процесса, вызывающего автономную функцию, создается отдельный пул. Это означает, что если 1-я автономная функция вызывает 2-ю автономную функцию, то 1-й автономный сеанс
также создает личный пул сеансов.
Процесс фонового рабочего запускается при запуске автономного сеанса
. Он устанавливает соединение с базой данных как аутентифицированный пользователь. Параметры сеанса, такие как search_path, копируются из основного сеанса. Максимальный размер пула составляет 100.
Так как autonomous session
является отдельным процессом, она содержит кэши и т.д. Чтобы предотвратить бесконечный рост использования ресурсов, мы сбрасываем все кэши по тайм-ауту, используя перезапуск autonomous session
. Этот тайм-аут задается настройкой guc `autonomous_session_lifetime`.
SQL-команды готовятся на автономном рабочем процессе и выполняются с использованием расширенного протокола запросов. Значения параметров передаются из переменных основной сессии. Результирующие строки возвращаются через протокол. Ошибки и уведомления передаются в основную сессию и повторно выбрасываются.
Курсоры, подготовленные операторы, динамический SQL с заполнителями для параметров требуют дополнительной поддержки протокола, которая пока не реализована.
Инфраструктура autonomous session
может поддерживать другие случаи использования, такие как параллельные рабочие запросы. Разделение выполнения запроса от основной сессии обеспечивает дополнительную гибкость. Однако не ожидается никакой выгоды в производительности по сравнению с текущими механизмами параллельных запросов.