Убедитесь, что сеанс php получает тот же сеанс оракула при использовании oci_pconnect

Я хотел бы использовать глобальные временные таблицы для хранения некоторых дорогостоящих промежуточных данных. Данные являются временными, но хорошими в течение всего сеанса php, поэтому кажется, что использование глобальных временных таблиц с on commit preserve rows будет идеальным.

Но .. похоже, что глобальные временные данные таблицы доступны только для сеанса oracle, который его создал.

Таким образом, возникает вопрос, как я могу гарантировать, что oci_pconnect вернет тот же сеанс оракула, как я прочитал, что сеансы oracle уникальны для постоянного соединения? Я не заинтересован в использовании транзакций в нескольких сценариях php, а только во временных таблицах.

Я использую php-сессии, чтобы их можно было использовать в качестве идентификатора для выбора сеанса oracle.

Пока кажется, что это просто невозможно, но это не помешает спросить.

EDIT : Целью реализации этой цели является ускорение доступа к информации о членстве в группе пользователей, используемой в моем управлении доступом.
Разбор группового членства заблаговременно и использование этих временных данных вместо этого исключает 3 + уровни объединений во всех последующих запросах. Поскольку возвращаемые ключи являются RAW , сериализация их во внешнем хранилище приводит к HEXTORAW() при использовании и, похоже, не помогает с намеченной целью.

Часть запроса, добавленного для определения доступа к групповому уровню, является статичной в течение всего сеанса и сама по себе возвращает приблизительно 600 строк уникальных 16-байтных RAW ключей. Эти ключи затем объединяются с результатами, установленными через таблицу ссылок, чтобы определить, имеет ли пользователь какие-либо привилегии «группового уровня» для набора результатов.

Я играл с использованием IN и передавал ключи в виде строки, но поскольку они представляют собой RAW-ключи, мне нужно вызвать HEXTORAW() 600 раз за запрос. Производительность была не так хороша, как использование временной таблицы и выполнение JOIN .

Есть ли другой способ сообщить Oracle сохранить результат этой части кэширования запроса, не доведя их до «постоянного» промежуточного результата?

Хотя вы можете придумать какую-то обман, чтобы сделать эту работу, по крайней мере, некоторое время, я полагаю, что это то, что почти наверняка вызовет проблемы в какой-то момент, особенно при переходе с сервера разработки на производственный сервер , Варианты могут включать:

  1. Используйте постоянную таблицу и очищайте данные, когда вы логически выполняете это.
  2. Напишите данные в плоский файл, а затем прочитайте его, когда это необходимо.
  3. Запишите данные в плоский файл, а затем смонтируйте файл как внешнюю таблицу.

Поделитесь и наслаждайтесь.

Как насчет «объединения пула резидентных баз данных». Наверное, это то, что ты ищешь. Дать ему шанс!