Disadvantages of using REFCURSORs from JDBC

Question

Hi,
Normally I write my SQL statements from inside Java (eg PreparedStatements).
I am investigating on creating PL/SQL Packages, supplying procedures and methods, which I can call from Java using CallableStatements. I understand the advantages of having a layer/API on the database side.
For example: retrieve some records from a table. (the PL/SQL function getCustomers returns a REFCURSOR)
- PreparedStatement (select ... from ... where ...) -> executeQuery -> loop ResultSet
- CallableStatement ("begin ? := getCustomers(); end;") -> cast getObject() to ResultSet -> loop ResultSet
What are the disadvantages of using the CallableStatement (REFCURSOR)?
Thanks, regards, Stephan

Answer 1

While that article may be a good intro for someone not familiar with JDBC it has some misinformation in it that can be misleading at best and cause performance and memory issues at worst.
Row-prefetching - there is little benefit to using a large value for this setting. As with most things extremes are to be avoided.
It is important to know how the data is going to be used. What is the point of bringing ALL the data from the DB in one call if you are going to write it to the file system. File I/O is generally the slowest part of an application.
It is also important that the code be scaleable. Apps should be written so that future modifications will impact existing functionality as little as possible. If you eat up the memory for one table or statement that limits the memory available for other uses. Worse, when things go wrong and you need to reduce the fetch setting you may now have problems everywhere because the testing you originally performed may have relied on that larger fetch setting.
If the data fetching is not done in its own thread then using a very large value can actually make an application appear to 'freeze' while it waits for the data fetch to complete.
A large fetch size can also waste significant amounts of memory; essentially allocating it but never using it and never allowing any other process to use it. This is because for a fetch size of 'n' Oracle has to allocate space for 'n' rows that are each of maximum size.
This wasted is most often due to the common VARCHAR2 datatype. Consider a single column defined as VARCHAR2(100). In the DB this column is stored as variable length. But Oracle will allocate 100 characters (could be multi-byte characters) in order to be able to hold a maximum length value.
If the actual data values never exceed 30 bytes then 70 bytes in each row are totally wasted. The more rows that are prefetched the more memory that is wasted simply in anticipation of a maximum length value that never occurs or only occurs rarely.
I've never used a prefetch/fetch size greater than one thousand and that was for tables with small records (no more than 10 or 20 columns).
And the Oracle docs don't even recommend a setting that high. See the JDBC Dev Guide
http://docs.oracle.com/cd/B19306_01/java.102/b14355/oraperf.htm#i1043756
>
Oracle Row-Prefetching Limitations
There is no maximum prefetch setting, but empirical evidence suggests that 10 is effective. Oracle has never observed a performance benefit to setting prefetch higher than 50. If you do not set the default row-prefetch value for a connection, then 10 is the default.