Shtock,

Не очень понятно, зачем?

Valergrad,

Беглый поиск в гугле, выдает "The Oracle Call Interface (OCI) client result cache is a memory area inside a client process that caches SQL query result sets for OCI applications. This client cache exists for each client process and is shared by all sessions inside the process. Oracle recommends client result caching for queries of read-only or read-mostly tables."


По запросу "Oracle JDBC result cache" гугл ничего мне не нашел.

Но, вроде, Prepared Statement'ы кешируются и соответственно кешируются все выделенные им ресурсы. В свое время с этим разбирался, но это скорее было проблемой, чем плюсом. Т.к. JDBC Prepared Statement'ы живут в рамках соединения, а современные приложения часто не открывают соединение, а просто берут его из пула случайным образом, то кэш Prepared Statement'ов забивался полностью случайными запросами (соединение фактически собирало мусор по всем модулям приложения) и получался жуткий overhead ресурсов.

Можно ли для Prepared Statement'а кешировать и итоговый Result Set, не помню. В практической ценности такой операции крайне сомневаюсь, если приложения работает поверх какого нибудь пула соединений. Т.к. кеш будет мгновенно замусориваться.

IMHO & AFAIK

OCI документация уверяет:

"This function (OCIStmtPrepare2) can be used with and without statement caching. This is determined at the time of connection or session pool creation. If caching is enabled for a session, then all statements in the session have caching enabled, and if caching is not enabled, then all statements are not cached ."

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

"OCI_PREP2_CACHE_SEARCHONLY - In this case, if the statement is not found (a NULL statement handle is returned), you must take further action. If the statement is found, OCI_SUCCESS is returned. Otherwise, OCI_ERROR is returned."

но практический смысл этой операции от меня ускользает.

Избежать попадание запроса в client result cache похоже что и никак (см. первую цитату)

IMHO

p.s. сам с этим не сталкивался

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

Т.к. приход от клиента одинаковых запросов да еще и в "близкое" время, это скорее похоже на ошибки разработки

Shtock...
то есть неясен смысл этого lag. Идёшь в БД любым statement и тебе приходит инвалидация. Наступает cache lag и этот же любой statement проверяет эти же инвалидации. Т.е. масло масляное.
Смысл lag (при этом дефолтно вроде вообще 3 сек., т.е. очень маленький) вполне понятен - банальное энергосбережение в ситуации если прикладной софт "отключился" (например для UI приложения - пользователь ушел на обед, а из приложения не вышел). В противном случае мы всегда будем забивать сеть пакетами для валидации кеша, а все технологии энергосбережение ОС пойдет коту под хвост.

Другое дело, что действительно получается масло-масленное и жуткий overhead на сеть, кроме валидации при round-trip'ах инициализирумых со стороны приложения, еще и round-trip'ы со стороны сервера отсылаются для валидации кеша.

Единственный бизнес применение, которое я могу себе _вообразить_ - real-time, когда задержка в 50-100 ms. уже критична. Тогда, скорее всего, такое кэширование и дублирование валидации может сократить задержки (latence). Ну или какие либо алгоритмы сервисов построенные на периодической опросе и, опять таки, с бизнес критичностью по времени (но не очень понятно насколько и чем при такой архитектуре думали программисты)

Но сам я ни разу с real-time приложениями завязанными на СУБД (а тем более Oracle) не сталкивался.

Мне вообще не очень понятен смысл кеширования на стороне OCI драйвера

Прикрутить к приложению или банальную LRUMap из Apache Commons (лично я бы на нем остановился), или, в случае желания делать "солидно" ( TM ), EhCache, кэшь хибернайта или прочее - получиться в приложении 100% управляемый кэш для _бизнес_ данных (а не убогих селектов). Занафига мучить этим Oracle?

А то у меня подозрение, что сначала программисты с тяжелой стадией "хибернейт головного мозга" написали приложение, которое 100500 мусорных запросов генерирует, а теперь с помощью subj пытаются заставить "крокодила летать" ((((

p.s. в свое время пытался смотреть на EhCache, но для меня не подходило. Мне нужны были очень хитрые правила инвалидации кэша. Прикрутить к EhCache свои правила инвалидации, мне показалось значительно сложнее, чем взять банальный LRUMap, дописать 10-50 строк кода и сделать собственный класс кэша. И проще, и надежнее.