• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

JDBC ResultSet

 
Ranch Hand
Posts: 906
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've got a question for JDBC specialists.
When you perform an executeQuery on a Statement like this :
Results rs = s.executeQuery("select ... where ...");
Is the ResultSet populated with ALL the rows from the query in one shot, or is it populated "on demand" when you perform a rs.next();
My understanding is that only JDBC 2.0 Scrollable Resultset offers the "on demand" feature, while with "classical" ResultSet, the whole rs is populated in one shot.
Is that correct ?
Any document on that subject is welcome.

Just to expplain my need, I want to set up a search feature in a 3-tier environment and to minimize :
- the number of access to the DB
- the amount of rows retrieve from the db when the client does not explicitally need to display them.
[ January 22, 2003: Message edited by: Bill Bailey ]
 
Ranch Hand
Posts: 1879
MySQL Database Suse
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
'classic' ResultSets bring into memory the amount of rows specified by the fetch size of the Statement. For example if fetch size = 10 and you have 100 results, then a classic resultset will fetch into memory the first 10, then when you rs.next() to the 11th row, it fetches the next 10 rows into memory, replacing the last 10. So at one time, you will have a maximum of 10 records held in memory.
Things are different for scrollable resultsets, depending on the vendor implementation. Generally, they work the same way as classic, except when it needs the the 11th row, it will keep the first 10 in memory. So the resultset grows in memory as you read more rows.
If you are looking for resultset paging techniques, have a look at this article which provides different solutions to this problem.
Jamie
 
JeanLouis Marechaux
Ranch Hand
Posts: 906
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Jamie it does help.
With the "fetch size" stuff, does it mean there is a DB access each time the fetch limit is reached.
So with your example, if the fetch size is 10, I'll have 10 db accesses to fetch all the rs, while there is only 1 db access with a fetch size = 100 ??
I've already read Claudio's article on TSS, but something is puzzling me.
Isn't it dangerous to use a scrollable result set for Large resultsets ?
I mean, if the client browses thru the whole RS , it is kept in memory.
So in a 3-tier application, can my app server be confronted by out of memory problems due to the scrollable resultset mechanism ?
 
There will be plenty of time to discuss your objections when and if you return. The cargo is this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic