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]
