views:

1667

answers:

3

I'm running tomcat and have some jsp pages that display a subset of a table. I show 20 rows at a time on a single page. When the table has large amounts of data, the jsp page doesn't render. I'm guessing that the ResultSet is using a client side cursor. I've worked with ASP in the past, and we always used server side forward only cursors, and never had any problems with large amounts of data. Our database is oracle 10g.

How can I specify a server-side forward-only cursor in JDBC?

A: 
Statement stmt = con.createStatement(ResultSet.TYPE_FORWARD_ONLY);
ResultSet rs = stmt.executeQuery(sql);

This should set it but apparently some drivers ignore it.

You could always try and set it again at ResultSet level.

rs.setFetchDirection(ResultSet.TYPE_FORWARD_ONLY);

Hope that helps.

adam
According to Connection createStatement documentation, the type is forward only by default... and really, with a large amount of data, the performance bonus is in the server-side cursor over the forward-only portion. I'll incorporate this though.
Kieveli
A: 
Kieveli
A: 

Not quite answering the question, but have you considered explicitly adding paging to your SELECT query using ROWNUM or ROWNUMBER in your WHERE clause?

eg: for the second page of data, 20 element page size:

SELECT * 
  FROM MyDataObjects
  WHERE rownum > 20 AND rownum < 41

This would ensure that at most one page of records are returned, removing the large cursor issue.

Dan Vinton
I think in oracle, you need to nest the rownum using a subquery... but we had considered it. Our system is quite complex and includes live filtering that is applied while viewing multiple lists of vastly different things... The dynamic SQL made it more difficult to page via the rownum.
Kieveli
In Oracle, rownum needs to be in a subquery only if you use ORDER BY... Oracle assigns rownum before doing the ORDER BY, so using where with rownum ends up selecting rows by their unsorted row number.
R. Bemrose
Whoops, that's what I get for writing queries without testing them. Thanks for the correction...
Dan Vinton