Поддерживает ли Oracle прокручиваемые курсоры на стороне сервера через JDBC? - PullRequest
Новая
       13

Поддерживает ли Oracle прокручиваемые курсоры на стороне сервера через JDBC?

2 голосов
/ 30 июня 2009

В настоящее время, работая над развертыванием ERP на основе OFBiz, мы столкнулись со следующей проблемой: часть кода платформы вызывает resultSet.last (), чтобы узнать общее количество строк набора результатов. Используя драйвер Oracle JDBC v11 и v10, он пытается кэшировать все строки в клиентской памяти, что приводит к сбою JVM из-за недостатка кучи.

После исследования проблема, похоже, заключается в том, что Oracle JDBC реализует Scrollable Cursor на стороне клиента, а не на сервере, используя кэш. Используя драйвер datadirect, эта проблема решается, но кажется, что вызов resultset.last () занимает слишком много времени, поэтому сервер приложений прерывает транзакцию

есть ли способ реализовать прокручиваемые курсоры через jdbc в oracle без обращения к драйверу datadirect?

а какой самый быстрый способ узнать длину заданного результата? Установить ??

Заранее спасибо Исмаэль

Ответы [ 2 ]

1 голос
/ 30 июня 2009

"Какой самый быстрый способ узнать длину заданного результата?" ЕДИНСТВЕННЫЙ способ действительно знать это считать их всех. Вы хотите знать, сколько SMITH в телефонной книге. Вы их считаете. Если это небольшой набор результатов, и он быстро получен, это не проблема. Например, в телефонной книге не будет много Гэндальфов, и вы, вероятно, все равно захотите получить их все.

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

Чтобы избежать кэширования всего набора результатов на клиенте, вы можете попробовать 

select id, count(1) over () n from junk;

Тогда у каждой строки будет дополнительный столбец (в данном случае n) с количеством строк в наборе результатов. Но все равно потребуется столько же времени, чтобы прийти к счетчику, так что все еще велика вероятность тайм-аута.

Компромисс - получить первые сто (или тысячу) рядов и не беспокоиться о разбивке на страницы.

0 голосов
/ 30 июня 2009

предложенный вами «обходной путь» со счетчиком в основном удваивает работу, выполняемую сервером БД. Сначала нужно пройтись по всему, чтобы посчитать количество результатов, а затем сделать то же самое + вернуть результаты. Гораздо лучше метод, упомянутый Гари (count (*) over () - аналитика). Но даже здесь весь набор результатов должен быть создан до того, как первый результат будет возвращен клиенту. Таким образом, это потенциально медленный расход памяти для больших выходных данных.

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

...