Что такое пул кеша

Обновлено: 04.07.2024

Вы можете использовать интерфейс командной строки (CLI) для создания, изменения и перечисления пулов кэша и директив кэша с помощью субкоманды hdfs cacheadmin.

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

Кэш-пулы идентифицируются уникальным строковым именем.

Сначала необходимо создать пул кэша, а затем добавить директивы кэша в пул кэша.

Команды кэширования пула

addPool — добавляет новый пул кэшей.

Таблица 3.1. Параметры добавления кэш-пула

< /th>

Параметр	Описание
	Имя пула.
	Имя пользователя владельца пула. По умолчанию текущий пользователь.
	Группа, которой назначен пул. По умолчанию используется имя основной группы текущего пользователя.
	Разрешения в стиле UNIX, назначенные пулу. Разрешения указываются в восьмеричном формате (например, 0755). Разрешения пула по умолчанию установлены на 0755.
	Максимальное количество байтов, которые могут кэшироваться директивами в пуле. , в совокупности. По умолчанию ограничение не установлено.
	Максимально допустимое время жизни для директив, добавляемых в пул. . Это может быть указано в секундах, минутах, часах и днях (например, 120 с, 30 минут, 4 часа, 2 дня). Допустимые единицы: [smhd]. По умолчанию максимальное значение не установлено. Значение «никогда» указывает, что ограничений нет.

modifyPool — изменяет метаданные существующего пула кэшей.

Таблица 3.2. Параметры изменения кэш-пула

< /th> < td align="left">owner

Параметр	Описание
name	Имя изменяемого пула.
Имя пользователя владельца пула.
группа	Группа, которой назначен пул.
режим	Разрешения в стиле UNIX, назначенные пулу. Разрешения указываются в восьмеричном формате (например, 0755).
limit	Максимальное количество байтов, которое может быть кэшируется директивами в пуле, в совокупности.
maxTtl	Максимально допустимое время жизни для директив, добавляемых в пул. Это может быть указано в секундах, минутах, часах и днях (например, 120 с, 30 минут, 4 часа, 2 дня). Допустимые единицы: [smdh]. По умолчанию максимальное значение не установлено. Значение «никогда» указывает, что ограничений нет.

removePool — удаляет пул кэшей. Эта команда также "не кэширует" пути, связанные с пулом.

Таблица 3.3. Параметры удаления кэш-пула

< /th>

listPools – отображает информацию об одном или нескольких пулах кэша, такую как имя, владелец, группа, разрешения и т. д.

Таблица 3.4. Параметры списка кэш-пулов

Параметр	Описание
name	Имя удаляемого кэш-пула.

< /th>

Параметр	Описание
статистика	Отображает дополнительную статистику кэш-пула.
name	Если указано, отображается только указанный пул кэшей.

help — отображает подробную информацию о команде.

Таблица 3.5. Параметры справки кэш-пула

< /th>

Параметры	Описание
	Отображает подробную информацию для указанного имени команды. Если имя команды не указано, для всех команд отображается подробная справка.

Команды директив кэширования

addDirective — добавляет новую директиву кэша.

Таблица 3.6. Кэш-пул Добавить параметры директивы

Параметр	Описание
	Путь к каталогу или файлу кеша.
	Пул кэша, в который будет добавлена директива кэша. У вас должно быть разрешение на запись для пула кэша, чтобы добавлять новые директивы.
	Пропускает проверку ресурса пула кэша. пределы.
	Используемый коэффициент репликации кэша. Значение по умолчанию – 1.
	Срок действия директивы. Это может быть указано в минутах, часах и днях (например, 30 минут, 4 часа, 2 дня). Допустимые единицы: [smdh]. Значение «никогда» указывает на то, что срок действия директивы никогда не истекает. Если не указано, срок действия директивы не ограничен.

removeDirective -- удаляет директиву кэша.

Таблица 3.7. Кэш-пулы Удалить параметры директивы

Параметр	Описание
	Идентификатор удаляемой директивы кэша. У вас должно быть разрешение на запись для пула, к которому принадлежит директива, чтобы удалить ее. Вы можете использовать команду -listDirectives для отображения списка идентификаторов директив кэша.

Параметр

Описание

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

removeDirectives — удаляет все директивы кэша по указанному пути.

Кэш-пулы — это логические репозитории элементов кэша. Они выполняют все обычные операции с элементами, такие как их сохранение или поиск. Пулы кэша не зависят от фактической реализации кэша. Таким образом, приложения могут продолжать использовать один и тот же пул кэша, даже если базовый механизм кэширования изменится с кэша на основе файловой системы на кэш на основе Redis или базы данных.

Создание пулов кеша

Пулы кэша создаются с помощью адаптеров кэша, которые представляют собой классы, реализующие как CacheInterface, так и Psr\Cache\CacheItemPoolInterface . Этот компонент предоставляет несколько адаптеров, готовых к использованию в ваших приложениях.

Использование контрактов кеша

CacheInterface позволяет извлекать, сохранять и удалять элементы кэша, используя только два метода и обратный вызов:

По умолчанию использование этого интерфейса обеспечивает защиту от давки за счет блокировки и досрочного истечения срока действия. Досрочное истечение срока действия можно контролировать с помощью третьего «бета» аргумента метода get(). Дополнительную информацию см. в статье Компонент кэша.

Досрочное истечение срока действия можно обнаружить внутри обратного вызова, вызвав метод isHit(): если он возвращает значение true , это означает, что в настоящее время мы пересчитываем значение до истечения срока его действия.

Для расширенных вариантов использования обратный вызов может принимать второй логический аргумент &$save, передаваемый по ссылке. Установив для $save значение false внутри обратного вызова, вы можете указать пулу кеша, что возвращаемое значение не должно сохраняться в серверной части.

Использование PSR-6

Поиск элементов кэша

Кэш-пулы определяют три метода поиска элементов кэша. Наиболее распространенным методом является getItem($key) , который возвращает элемент кеша, идентифицированный данным ключом:

Если для данного ключа не определен ни один элемент, метод возвращает не нулевое значение, а пустой объект, который реализует класс CacheItem.

Если вам нужно получить несколько элементов кеша одновременно, используйте метод getItems([$key1, $key2, . ]):

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

Последний метод, связанный с получением элементов кеша, — это hasItem($key) , который возвращает значение true, если есть элемент кеша, идентифицированный данным ключом:

Сохранение элементов кэша

Наиболее распространенным методом сохранения элементов кеша является Psr\Cache\CacheItemPoolInterface::save , который немедленно сохраняет элемент в кеше (возвращает true, если элемент был сохранен, или false, если произошла ошибка):

Иногда вы можете предпочесть не сохранять объекты сразу, чтобы повысить производительность приложения. В таких случаях используйте метод Psr\Cache\CacheItemPoolInterface::saveDeferred, чтобы пометить элементы кэша как «готовые к сохранению», а затем вызовите метод Psr\Cache\CacheItemPoolInterface::commit, когда вы будете готовы сохранить их все:

Метод saveDeferred() возвращает значение true, если элемент кеша был успешно добавлен в "очередь сохранения", и значение false в противном случае. Метод commit() возвращает значение true, если все ожидающие элементы успешно сохранены, или значение false в противном случае.

Удаление элементов кэша

Пулы кеша включают методы удаления элемента кеша, некоторых из них или всех. Наиболее распространенным является Psr\Cache\CacheItemPoolInterface::deleteItem , который удаляет элемент кэша, идентифицированный данным ключом (возвращает true, если элемент успешно удален или не существует, и false в противном случае):

Используйте метод Psr\Cache\CacheItemPoolInterface::deleteItems для одновременного удаления нескольких элементов кэша (он возвращает значение true, только если все элементы были удалены, даже если какие-либо или некоторые из них не существуют):

Наконец, чтобы удалить все элементы кеша, хранящиеся в пуле, используйте метод Psr\Cache\CacheItemPoolInterface::clear (который возвращает true при успешном удалении всех элементов):

Если компонент кеша используется внутри приложения Symfony, вы можете удалить элементы из пулов кеша, используя следующие команды (которые находятся в пакете фреймворка):

Чтобы удалить один конкретный элемент из данного пула:

Вы также можете удалить все элементы из данного пула(ов):

Сокращение элементов кэша

Некоторые пулы кеша не включают автоматизированный механизм удаления просроченных элементов кеша. Например, кеш FilesystemAdapter не удаляет элементы кэша с истекшим сроком действия, пока элемент явно не запрошен и не определен как просроченный, например, посредством вызова Psr\Cache\CacheItemPoolInterface::getItem . При определенных рабочих нагрузках это может привести к тому, что устаревшие записи кэша будут сохраняться после истечения срока их действия, что приведет к значительному потреблению дискового пространства или памяти из-за избыточных элементов кэша с истекшим сроком действия.

Этот недостаток устранен путем введения PruneableInterface, который определяет абстрактный метод prune(). ChainAdapter, FilesystemAdapter, PdoAdapter и PhpFilesAdapter реализуют этот новый интерфейс, позволяющий вручную удалять устаревшие элементы кэша:

Реализация ChainAdapter сама по себе не содержит никакой логики сокращения. Вместо этого при вызове метода prune() адаптера цепочки вызов делегируется всем его совместимым адаптерам кэша (а те, которые не реализуют PruneableInterface, молча игнорируются):

Если компонент кеша используется внутри приложения Symfony, вы можете удалить все элементы из всех пулов с помощью следующей команды (которая находится в пакете фреймворка):< /p>

Используйте пул быстрых устройств хранения (возможно, SSD) и используйте его в качестве кэша для существующего более медленного и крупного пула.

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

Мы должны иметь возможность создавать и добавлять пул кэша в существующий пул данных, а затем удалять его, не прерывая работу службы или перенося данные.

Случаи использования

Пул чтения-записи, обратная запись

У нас есть существующий пул данных, и мы поместили перед ним пул быстрого кэширования. Записи отправляются в пул кеша и немедленно подтверждаются. Мы сбрасываем их обратно в пул данных на основе определенной политики.

Пул только для чтения, слабая согласованность

У нас есть существующий пул данных, и мы добавляем один или несколько пулов кеша только для чтения. Мы копируем данные в пул(ы) кеша при чтении. Записи перенаправляются в исходный пул данных. Устаревшие данные удаляются из пулов кэша в соответствии с определенной политикой.

Вероятно, это полезно только для определенных приложений с определенными схемами доступа к данным. Например, это может быть совпадение для rgw.

Интерфейс

Настройте пул кеша чтения/записи foo-hot для пула foo:

Направить весь трафик для foo на foo-hot:

Установите целевой размер и включите агент многоуровневого хранения для foo-hot:

Очистить кеш перед отключением:

Когда пул кеша окончательно опустеет, отключите его:

Пулы только для чтения с отложенной согласованностью:

Агент по уровням

Политика многоуровневого хранения определяется как свойства самого пула кэшей.

Метаданные HitSet

Во-первых, агенту требуется отслеживание информации HitSet в пуле кэша, чтобы определить, к каким объектам в пуле осуществляется доступ. Это включается с помощью:

Поддерживаемые типы HitSet включают «bloom» (фильтр Блума, значение по умолчанию), «explicit_hash» и «explicit_object». Последние два явно перечисляют объекты, к которым осуществляется доступ, и менее эффективно используют память. Они предназначены в первую очередь для отладки и демонстрации возможности подключения к инфраструктуре. Для типа фильтра Блума можно дополнительно определить вероятность ложного срабатывания фильтра Блума (по умолчанию 0,05):

Параметры hit_set_count и hit_set_period определяют, сколько времени должен охватывать каждый HitSet и сколько таких HitSet хранить. Биннинг доступа во времени позволяет Ceph независимо определять, был ли доступ к объекту хотя бы один раз и был ли доступ к нему более одного раза за некоторый период времени («возраст» против «температуры»).

min_read_recency_for_promote определяет, сколько наборов совпадений нужно проверять на наличие объекта при обработке операции чтения. Результат проверки используется для принятия решения о том, продвигать ли объект асинхронно. Его значение должно быть между 0 и hit_set_count. Если установлено значение 0, объект всегда продвигается. Если установлено значение 1, проверяется текущий HitSet. И если этот объект находится в текущем HitSet, он продвигается. В противном случае нет. Для других значений проверяется точное количество архивных наборов совпадений. Объект повышается, если он найден в одном из самых последних наборов совпадений min_read_recency_for_promote.

Аналогичный параметр можно задать для операции записи: min_write_recency_for_promote .

Обратите внимание, что чем дольше hit_set_period и чем выше min_read_recency_for_promote/min_write_recency_for_promote, тем больше оперативной памяти будет потреблять процесс ceph-osd. В частности, когда агент активно очищает или удаляет объекты кэша, все наборы совпадений hit_set_count загружаются в ОЗУ.

Режим кэширования

Наиболее важной политикой является режим кэширования:

ceph osd pool устанавливает обратную запись в режиме foo-hot cache-mode

Поддерживаемые режимы: «нет», «обратная запись», «пересылка» и «только чтение». В большинстве установок требуется «обратная запись», которая будет записывать в уровень кэша и только позже сбрасывать обновления обратно на базовый уровень. Точно так же любой прочитанный объект будет переведен на уровень кэша.

Режим «вперед» предназначен для случаев, когда кеш отключен и его необходимо очистить. Никакие новые объекты не будут продвигаться или записываться в пул кэша, если они уже не присутствуют. Затем фоновая операция может сделать что-то вроде:

для принудительного сброса всех данных обратно на базовый уровень.

Режим «только для чтения» предназначен для рабочих нагрузок только для чтения, которые не требуют обеспечения согласованности со стороны системы хранения. Записи будут перенаправлены на базовый уровень, но прочитанные объекты будут перемещены в кэш. Ceph не предпринимает никаких попыток обеспечить согласованность содержимого уровня(ей) кэша при наличии обновлений объектов.

Размер кэша

Агент выполняет две основные функции: сброс (запись «грязных» объектов кэша обратно на базовый уровень) и удаление (удаление холодных и чистых объектов из кэша).

Пороги, при которых Ceph будет сбрасывать или удалять объекты, указываются относительно «целевого размера» пула. Например:

начнет сбрасывать грязные объекты, когда 40 % пула будут грязными, и начнет удалять чистые объекты, когда мы достигнем 80 % целевого размера.

Целевой размер может быть указан как в объектах, так и в байтах:

Обратите внимание, что если указаны оба предела, Ceph начнет сброс или вытеснение при срабатывании любого порога.

Другие настройки

Вы можете указать минимальный возраст объекта, по истечении которого недавно обновленный объект будет сброшен на базовый уровень:

Вы можете указать минимальный возраст объекта, по истечении которого он будет удален из уровня кеша:

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

Кэширование соединений использует структуру пула соединений, такую как источники данных пула соединений и соединения в пуле, в большинстве своих операций. Эта структура описана в разделе "Пул соединений", начиная с .

Спецификация JDBC 2.0 не требует реализации кэширования соединений, но Oracle предоставляет простую реализацию, которая может служить хотя бы в качестве примера.

Этот раздел разделен на следующие темы:

Концепция кэширования соединения не имеет отношения к внутреннему драйверу на стороне сервера, где вы просто используете подключение по умолчанию, и применима только к тонкому драйверу на стороне сервера в рамках одного сеанса.

Обзор кэширования соединений

Каждый кеш подключения представлен экземпляром класса кеша подключения и имеет связанную группу объединенных в пул экземпляров подключения. Для одного экземпляра кэша соединений все связанные экземпляры соединений в пуле должны представлять физические соединения с одной и той же базой данных и схемой. Экземпляры соединения в пуле создаются по мере необходимости, то есть всякий раз, когда запрашивается соединение, а в кэше соединений нет свободных экземпляров соединения в пуле. «Свободный» объединенный в пул экземпляр соединения — это экземпляр, с которым в настоящее время не связан логический экземпляр соединения; другими словами, экземпляр объединенного соединения, физическое соединение которого не используется.

Основы настройки кэша соединений

Промежуточный уровень при настройке кэша подключения создаст экземпляр класса кэша подключения и установит соответствующие свойства подключения к источнику данных, например serverName , databaseName или URL . Напомним, что класс кэша соединения расширяет класс источника данных. Дополнительные сведения о свойствах источника данных см. в разделе «Свойства источника данных».

Примером класса кэша соединений является OracleConnectionCacheImpl . Как создать экземпляр этого класса и установить его свойства подключения, описано в разделе «Создание экземпляра OracleConnectionCacheImpl и установка свойств». Этот класс расширяет класс OracleDataSource и, таким образом, включает в себя методы установки для установки свойств соединения, чтобы указать базу данных, к которой необходимо подключиться. Все экземпляры соединения в пуле в кэше будут представлять физические соединения с этой же базой данных и фактически с одной и той же схемой.

После того как средний уровень создал экземпляр кэша подключения, он может дополнительно связать этот экземпляр с JNDI, как и с любым экземпляром источника данных, как описано в разделе «Регистрация источника данных».

Основы доступа к кешу подключений

Приложение JDBC должно получить экземпляр кэша подключения, чтобы использовать кэш. Обычно это достигается через средний уровень, часто с использованием поиска JNDI. В сценарии кэширования соединения поиск JNDI вернет экземпляр кэша соединения вместо универсального экземпляра источника данных. Поскольку класс кэша подключения расширяет класс источника данных, экземпляры кэша подключения включают в себя функции источника данных.

Выполнение поиска JNDI описано в разделе "Открытие соединения".

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

Основы открытия контактов

Класс кеша соединений, как и объединенный класс соединений, имеет метод getConnection(). Метод getConnection() экземпляра кэша соединений возвращает логическое соединение с базой данных и схемой, связанной с кэшем. Эта связь осуществляется через свойства подключения экземпляра кэша подключения, как обычно задается средним уровнем.

Всякий раз, когда приложению JDBC требуется подключение к базе данных в сценарии кэширования подключения, оно вызывает метод getConnection() экземпляра кэша подключения, связанного с базой данных.

Этот метод getConnection() проверяет, есть ли в кеше свободные экземпляры соединений из пула. Если нет, то создается. Затем экземпляр логического соединения будет извлечен из ранее существовавшего или вновь созданного экземпляра соединения в пуле, и этот экземпляр логического соединения будет предоставлен приложению.

Основы закрытия соединений: использование событий соединения

JDBC использует события в стиле JavaBeans, чтобы отслеживать, когда физическое соединение (экземпляр объединенного соединения) может быть возвращено в кэш или когда оно должно быть закрыто из-за неустранимой ошибки. Когда приложение JDBC вызывает метод close() экземпляра логического соединения, событие инициируется и передается прослушивателю событий или прослушивателям, связанным с объединенным экземпляром соединения, создавшим экземпляр логического соединения. Это инициирует событие закрытия соединения и информирует экземпляр соединения в пуле о том, что его физическое соединение можно использовать повторно. По сути, это помещает экземпляр соединения в пуле и его физическое соединение обратно в кеш.

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

Кэш-класс также может реализовать класс прослушивателя событий соединения. В этом случае прослушиватель событий подключения является частью экземпляра кэша подключения. (В примере реализации Oracle это не так.) Однако даже в этом случае необходимо установить явную связь между прослушивателем событий соединения и каждым экземпляром соединения в пуле.

Сценарии реализации

Разработчики среднего уровня могут реализовать свой собственный класс кэширования соединений и класс прослушивателя событий соединения.

Однако для удобства Oracle предоставляет в пакете oracle.jdbc.pool следующее:

Класс OracleConnectionCacheImpl — это простая реализация класса кэша соединений, которую Oracle предоставляет в качестве примера и которая обеспечивает достаточную, но минимальную функциональность. Он реализует интерфейс OracleConnectionCache и использует экземпляры класса OracleConnectionEventListener для событий подключения.

Если вам требуется больше функциональных возможностей, чем может предложить OracleConnectionCacheImpl, но при этом вы хотите использовать OracleConnectionEventListener для событий подключения, вы можете создать собственный класс, реализующий OracleConnectionCache .

Или вы можете создать свой собственный класс кэширования соединений и класс прослушивателя событий соединения с нуля.

Обычные шаги по использованию кэша соединений

В этом разделе перечислены общие этапы того, как приложение JDBC и промежуточный уровень будут использовать кэш соединения при открытии и закрытии логического соединения.

Предварительные этапы кэширования соединения

Предположим, что следующее уже выполнено:

<ПР> Средний уровень создал экземпляр кэша подключения, как описано в разделе «Основы настройки кэша подключения».

Общие шаги по открытию соединения

После того как приложение JDBC получает доступ к экземпляру кэша соединения, приложение и промежуточный уровень выполняют следующие шаги, чтобы создать экземпляр логического соединения для использования приложением:

<ПР> Приложение запрашивает соединение с помощью метода getConnection() экземпляра кэша соединений. Вводить данные не требуется, поскольку экземпляр кэша соединений уже связан с определенной базой данных и схемой.

То, что именно происходит в ситуации, когда нет доступных экземпляров соединений из пула, зависит от схемы реализации и от того, ограничен ли кеш максимальным числом соединений в пуле. Для примера реализации Oracle это обсуждается в «Схемах создания новых объединенных в пул соединений в реализации Oracle».

В некоторых реализациях создание и сопоставление прослушивателя событий соединения может происходить только при первом создании экземпляра соединения в пуле. В примере реализации Oracle это также происходит каждый раз при повторном использовании экземпляра соединения из пула.

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

Для getConnection() ввод данных не требуется, поскольку экземпляр соединения из пула уже связан с определенной базой данных и схемой.

Приложение JDBC использует этот экземпляр логического соединения так же, как и любой другой экземпляр соединения.

Общие шаги по закрытию соединения

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

<ПР> Приложение вызывает метод close() для экземпляра логического соединения (как и для любого экземпляра соединения).

Прослушиватель событий подключения обычно выполняет эти шаги, вызывая методы экземпляра кэша подключения, что зависит от реализации. В примере реализации Oracle эти функции выполняются методами, указанными в интерфейсе OracleConnectionCache, как описано в разделе "Спецификация кэша соединений Oracle: интерфейс OracleConnectionCache" .

В некоторых реализациях этот шаг может быть выполнен только тогда, когда экземпляр соединения в пуле закрыт либо из-за неустранимой ошибки, либо из-за того, что приложение завершило работу с физическим соединением. Однако в примере реализации Oracle прослушиватель событий соединения отключается от экземпляра соединения из пула каждый раз, когда соединение из пула возвращается в доступный кэш (поскольку в реализации Oracle прослушиватель событий соединения связан с экземпляром соединения из пула всякий раз, когда он используется повторно).

Спецификация Oracle Connection Cache: интерфейс OracleConnectionCache

Разработчики среднего уровня могут свободно реализовывать свою собственную схему кэширования соединений по своему усмотрению, но Oracle предлагает интерфейс OracleConnectionCache, который можно реализовать в классе кэширования соединений и который использует экземпляры класса OracleConnectionEventListener для своих функций прослушивателя.

Кроме того, Oracle предлагает класс, реализующий этот интерфейс, OracleConnectionCacheImpl , который можно использовать как есть. Этот класс также расширяет класс OracleDataSource и, следовательно, включает в себя метод getConnection(). Дополнительные сведения об этом классе см. в разделе «Реализация кэша соединений Oracle: класс OracleConnectionCacheImpl».

Все эти классы и интерфейсы Oracle находятся в пакете oracle.jdbc.pool.

Интерфейс OracleConnectionCache определяет следующие методы (в дополнение к методам источника данных, которые он наследует), которые должны быть реализованы в классе кэша соединения:

Этот метод будет вызываться прослушивателем событий соединения после того, как приложение JDBC завершит использование экземпляра логического соединения, предоставленного экземпляром соединения из пула (благодаря предыдущему использованию метода getConnection() соединения из пула).

Прослушиватель событий соединения будет вызывать этот метод после возникновения неустранимой ошибки в экземпляре логического соединения, предоставленном экземпляром соединения в пуле. Слушатель вызовет closePooledConnection() , например, если заметит сбой сервера.

Функциональность методов reusePooledConnection() и closePooledConnection() является реализацией некоторых шагов, описанных в целом в разделе "Общие действия по закрытию соединения".

Реализация кэша соединений Oracle: класс OracleConnectionCacheImpl

Oracle предлагает пример реализации кэширования подключений и прослушивателей событий подключения, предоставляя класс OracleConnectionCacheImpl. Этот класс реализует интерфейс OracleConnectionCache (который вы можете реализовать самостоятельно в другом классе кэша соединений) и использует экземпляры класса OracleConnectionEventListener для функций прослушивателя.

Все эти классы и интерфейсы Oracle находятся в пакете oracle.jdbc.pool.

Если вы используете класс OracleConnectionCacheImpl для функции кэширования соединения, вы должны быть знакомы со следующими темами, обсуждаемыми непосредственно ниже:

OracleConnectionCacheImpl поддерживает JNDI не полностью в Oracle8 i версии 8.1.6 и выше — экземпляр, полученный с помощью вызова поиска, не имеет открытых соединений; однако свойства подключения, схема кэширования и ограничения на количество подключений в пуле сохраняются.

Создание экземпляра OracleConnectionCacheImpl и установка свойств

Средний уровень, использующий реализацию кэширования соединения Oracle, может создать экземпляр OracleConnectionCacheImpl и установить его свойства соединения одним из трех способов:

Это эквивалентно установке свойств в любом универсальном источнике данных или источнике данных пула соединений, как описано в разделе "Инициализация свойств соединения".

Установка максимального количества подключений в пуле

В любой реализации кэширования соединений разработчик среднего уровня должен решить, должно ли быть максимальное количество соединений в пуле в кэше, и как поступать в ситуациях, когда соединения в пуле недоступны, а максимальное количество достигнуто.< /p>

Класс OracleConnectionCacheImpl включает максимальный размер кэша, который можно установить с помощью метода setMaxLimit() (принимая в качестве входных данных целое число). Значение по умолчанию – 1.

Ниже приведен пример, предполагающий, что ocacheimpl является экземпляром OracleConnectionCacheImpl:

В этом примере максимальный размер кеша ограничен 10 экземплярами соединения в пуле.

Схемы создания новых объединенных соединений в реализации Oracle

Класс OracleConnectionCacheImpl поддерживает три схемы кэширования соединений. Используйте эти схемы в ситуациях, когда (1) приложение запросило соединение, (2) все существующие соединения из пула используются и (3) достигнуто максимальное количество соединений из пула в кэше.

В этой схеме по умолчанию вы можете создавать новые соединения в пуле сверх максимального предела, но каждое из них автоматически закрывается и освобождается, как только предоставленный экземпляр логического соединения больше не используется. (В отличие от обычного сценария, когда использование экземпляра соединения из пула завершено, и он возвращается в доступный кэш.)

В этой схеме максимальный лимит не может быть превышен. Запросы на соединения, когда максимальное количество уже достигнуто, вернут null .

То же, что и схема "фиксированное без ожидания", за исключением того, что запрос на новое подключение будет ожидать, если достигнуто ограничение на количество подключений. В этом случае запрос на подключение ожидает, пока другой клиент не разорвет соединение.

Установите схему кэширования, вызвав метод setCacheScheme() экземпляра OracleConnectionCacheImpl. Используйте в качестве входных данных одну из следующих статических констант класса:

Например, предположим, что ocacheimpl является экземпляром OracleConnectionCacheImpl:

Дополнительные методы OracleConnectionCacheImpl

В дополнение к ключевым методам, уже рассмотренным в разделе "Спецификация кэша соединений Oracle: интерфейс OracleConnectionCache" , могут быть полезны следующие методы OracleConnectionCacheImpl:

Прослушиватель событий подключения к Oracle: класс OracleConnectionEventListener

В этом разделе обсуждается функциональность OracleConnectionEventListener путем обобщения его конструкторов и методов.

Создание экземпляра прослушивателя событий подключения к Oracle

В реализации Oracle кэширования соединения экземпляр OracleConnectionCacheImpl создает прослушиватель событий соединения Oracle, указывая сам экземпляр кэша соединения (его экземпляр this) в качестве аргумента конструктора. Этот экземпляр связывает прослушиватель событий подключения с экземпляром кэша подключения.

Однако в целом конструктор OracleConnectionEventListener может принимать в качестве входных данных любой экземпляр источника данных. Например, где ds — общий источник данных:

Есть также конструктор по умолчанию, который не принимает никаких входных данных и может использоваться в сочетании с методом setDataSource() класса OracleConnectionEventListener:

Входными данными могут быть любые источники данных, включая экземпляр OracleConnectionCacheImpl (поскольку этот класс расширяет OracleDataSource ).

Методы прослушивателя событий подключения к Oracle

В этом разделе кратко описаны методы класса OracleConnectionEventListener:

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

В любом кэше может быть только один пул каждого размера ввода-вывода. Общий размер пулов в любом кэше не может быть больше размера самого кэша. Минимальный размер пула памяти равен размеру логической страницы сервера. Пулы памяти большего размера должны быть степенью двойки и иметь максимальный размер одного экстента.

Когда SAP ASE выполняет большие операции ввода-вывода, несколько страниц одновременно считываются в кэш. Эти страницы всегда рассматриваются как единое целое; они устаревают в кэше и записываются на диск как единое целое.

По умолчанию при создании именованного кэша данных все его пространство назначается пулу памяти по умолчанию. Создание дополнительных пулов переназначает часть этого пространства другим пулам, уменьшая размер пула памяти по умолчанию. Например, если вы создаете кеш данных размером 50 МБ, все пространство назначается пулу 2 КБ. Если вы настроите пул 4K с 30 МБ места в этом кэше, пул 2K уменьшится до 20 МБ.

После создания пулов вы можете перемещать пространство между ними. Например, в кэше с 20-мегабайтным пулом 2K и 30-мегабайтным 4K-пулом можно настроить 16-килобайтный пул, выделив 10 МБ пространства из 4K-пула.

Команды, которые перемещают пространство между пулами в кэше, не требуют перезапуска SAP ASE, поэтому вы можете перенастроить пулы в соответствии с изменяющимися нагрузками приложений, практически не влияя на работу сервера.

Помимо создания пулов в настраиваемых кэшах, вы можете добавить пулы памяти для операций ввода-вывода до 16 КБ в кэш данных по умолчанию.

Для config_pool задан размер, указанный в команде. Пространство перемещается в или из второго пула, затронутого_пула. Если вы не укажете затронутый_пул, пространство будет взято или выделено для пула 2 КБ (наименьший доступный размер). Минимальный размер пула – 512 КБ.

Вы также можете создавать пулы памяти в кэше данных по умолчанию.

Вам не нужно настраивать размер пула памяти 2 КБ в создаваемых кэшах. Его Run Size представляет всю память, которая явно не настроена для других пулов в кэше.

Читайте также: