jive疑惑


  
    protected long[] getThreadBlock(String query, int startIndex){
     

try {
con = ConnectionManager.getConnection();
stmt = con.createStatement();
// Set the maxium number of rows to end at the end of this block.
ConnectionManager.setMaxRows(stmt, THREAD_BLOCK_SIZE * (blockID+1));
ResultSet rs = stmt.executeQuery(query);
// Grab THREAD_BLOCK_ROWS rows at a time.
ConnectionManager.setFetchSize(rs, THREAD_BLOCK_SIZE);
// Many JDBC drivers don't implement scrollable cursors the real
// way, but instead load all results into memory. Looping through
// the results ourselves is more efficient.

for (int i=0; i<blockStart; i++) {
rs.next();
}


这是jive中获得当前页面id子集合的代码, ForumThreadBlockIterator 每次得到下一个页面的时候都会调用这个方法,也就是说每次都会进行数据库查询,而且查询的并不是THREAD_BLOCK_SIZE 行.是THREAD_BLOCK_SIZE * (blockID+1)行;这样是不是太浪费时间了.我想这样做是为了在collection中只储存当前页面的id,数据库查询的消耗难道不比内存中的消耗大么?
 

1.jive的分页查询是每次到下一个页面的时候进行一次数据库查询一次,而且查询的是THREAD_BLOCK_SIZE * (blockID+1)行,但是在内存中只放了一页的数据.在通过iterator进行输出,在数据库的查询上,还是在内存中是很好的.
2.而page-by-page iteration模式也是每次到下一个页面的时候进行一次数据库查询,但是查询时每次都是把数据库中的符合条件的结果全部查出,但在内存中放一页的数据.在通过iterator进行输出.
3.当然jive的iterator是经过jive自己写的类,为什么要写这个类呢,是因为jive在进行数据库查询的时候先把所有的符合条件的id查出来,在用iterator进行输出的时候,才进行完整对象的数据库查询.
4,而page-by-page iteration模式中的iterator是java中集合自带的,所以用这个模式的时候是把所有一次性查出.不是先查id.在得到完整对象.
5.我个人总结一下bang先生的批量分页查询的完美解决之道中的说法(当然我也可能误解了他的意思),也就是在DAO中的getList()操作中返回pageIterator.也就是一页的iterator.那么getList()的实现到底是象page-by-page iteration模式那样每次都查询所有符合条件的结果,还是象jive中查询一部分呢,当然jive中的实现过于烦琐,感觉不舒服,但确实有一定的优化.page-by-page iteration呢简洁些,我想还是象bang说的用page-by-page iteration好一点.让人看这舒服.