sounds like there is a chance to do a platform specific optimization that starts at 
and rturns a limited number of rows for Oracle. Anyone know the specifics of how to do 
this? I'm thinking something along the lines of the .size() vs COUNT(*) method of 
finding the number of returned results.

-----Original Message-----
From: Ebersole, Steven [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 25, 2003 11:13 AM
To: 'OJB Users List'
Subject: RE: Using setStartAtIndex with Oracle 8i


Not sure how it actually gets filled (all at once vs asynchronously).

FYI, 9i does support scrollable cursors and I believe that is then extended
into the JDBC drivers.  Might want to check out upgrading if this is a big
concern.



    |-----Original Message-----
    |From: Andrew Gilbert [mailto:[EMAIL PROTECTED]
    |Sent: Tuesday, March 25, 2003 12:47 PM
    |To: OJB Users List
    |Subject: RE: Using setStartAtIndex with Oracle 8i
    |
    |
    |Learn something new every day...
    |
    |http://otn.oracle.co.kr/docs/Oracle817/java.817/a83724/resl
    |tse1.htm#1017614
    |
    |Steven is correct, in that the db doesn't implement 
    |scrollable cursors, so the Oracle solution is dependent on 
    |client side caching. 
    |
    |It isn't clear to me how fast the cache gets filled, ie 
    |all at once or in response to movement. In our case we are 
    |paging and seldom ever iterate more than a few percentage 
    |points of a large set. Perhaps that explains our ignorant 
    |happiness?
    |
    |So we obviously need to look at OracleResultSetCache as well.
    |
    |Thanks Steven.
    |
    |> -----Original Message-----
    |> From: Ebersole, Steven [mailto:[EMAIL PROTECTED]
    |> Sent: Tuesday, March 25, 2003 12:57 PM
    |> To: 'OJB Users List'
    |> Subject: RE: Using setStartAtIndex with Oracle 8i
    |> 
    |> 
    |> Oracle 8i (and previous) does _not_ support scrollable 
    |> cursors.  Thus, the
    |> entire result set is transferred into a client-side memory 
    |> cache for result
    |> sets declared as scrollable.  All result set methods are 
    |then executed
    |> against this memory cache.  Obviously, for very large cursors 
    |> this will be
    |> very inefficient.
    |> 
    |> Your best options are:
    |> 1) Don't use scrollable result sets;
    |> 2) Implement a better client-side cursor cache ( see the 
    |> javadocs for the
    |> OracleResultSetCache interface for more details)
    |> 
    |> 
    |> 
    |> 
    |>     |-----Original Message-----
    |>     |From: Matthew Baird [mailto:[EMAIL PROTECTED]
    |>     |Sent: Tuesday, March 25, 2003 11:40 AM
    |>     |To: OJB Users List
    |>     |Subject: RE: Using setStartAtIndex with Oracle 8i
    |>     |
    |>     |
    |>     |are there any oracle experts that could shed some 
    |light on this.
    |>     |
    |>     |the actual code should not bring back all the results and 
    |>     |only return a subset, but rather it should use the 
    |>     |ResultSet.absolute method to bop around and only retrieve 
    |>     |the objects it needs. This code is in RsIterator and 
    |>     |PersistenceBrokerImpl
    |>     |
    |>     |anyone?
    |>     |
    |>     |-----Original Message-----
    |>     |From: [EMAIL PROTECTED] 
    |>     |[mailto:[EMAIL PROTECTED]
    |>     |Sent: Tuesday, March 25, 2003 9:29 AM
    |>     |To: OJB Users List
    |>     |Subject: RE: Using setStartAtIndex with Oracle 8i
    |>     |
    |>     |
    |>     |
    |>     |Hi,
    |>     |
    |>     |I think when you use setStartIndex method, all the results 
    |>     |are retrieved
    |>     |from DB and then your query returns only the subset that 
    |>     |you specified.
    |>     |I ran into that problem too and I had to add an additional 
    |>     |criteria to my
    |>     |query :
    |>     |
    |>     |Criteria crit = new Criteria();
    |>     |crit.addSql("rownum < 100");
    |>     |Query q = QueryFactory.newQuery(Foo.class, crit);
    |>     |Collection c = broker.getCollectionByQuery(q);
    |>     |
    |>     |The problem is that it uses oracle specific stuff.
    |>     |But at least, performance is much better !
    |>     |Hope that helps,
    |>     |
    |>     |Thomas
    |>     |
    |>     |
    |>     |
    |>     |-----------------------------------------------------------
    |>     |----------
    |>     |To unsubscribe, e-mail: [EMAIL PROTECTED]
    |>     |For additional commands, e-mail: [EMAIL PROTECTED]
    |>     |
    |>     |
    |>     |-----------------------------------------------------------
    |>     |----------
    |>     |To unsubscribe, e-mail: [EMAIL PROTECTED]
    |>     |For additional commands, e-mail: [EMAIL PROTECTED]
    |>     |
    |> 
    |> 
    |-----------------------------------------------------------
    |----------
    |> To unsubscribe, e-mail: [EMAIL PROTECTED]
    |> For additional commands, e-mail: [EMAIL PROTECTED]
    |> 
    |> 
    |
    |-----------------------------------------------------------
    |----------
    |To unsubscribe, e-mail: [EMAIL PROTECTED]
    |For additional commands, e-mail: [EMAIL PROTECTED]
    |

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to