Looks like Steven's reply contra indicates mine. Hmm...
What I can say definitively is the following:

1. The following features assert true with an Oracle 8.1.7 db using thin driver with 
20 in the url:
         assertTrue("Supports forward-only ResultSets", // not refreshRow()
                    db.supportsResultSetType(ResultSet.TYPE_FORWARD_ONLY));

         assertTrue("Supports scroll-insensitive ResultSets",
                    db.supportsResultSetType(ResultSet.TYPE_SCROLL_INSENSITIVE));
         assertTrue("Supports scroll-insensitive ResultSets with read-only 
concurrency",
                    db.supportsResultSetConcurrency(ResultSet.CONCUR_READ_ONLY,// not 
refreshRow()
                                                    
ResultSet.TYPE_SCROLL_INSENSITIVE));
         assertTrue("Supports scroll-insensitive ResultSets with updatable 
concurrency",
                    db.supportsResultSetConcurrency(ResultSet.CONCUR_UPDATABLE,
                                                    
ResultSet.TYPE_SCROLL_INSENSITIVE));

         assertTrue("Supports scroll-sensitive ResultSets",
                    db.supportsResultSetType(ResultSet.TYPE_SCROLL_SENSITIVE));
         assertTrue("Supports scroll-sensitive ResultSets with read-only concurrency",
                    db.supportsResultSetConcurrency(ResultSet.CONCUR_READ_ONLY,
                                                    ResultSet.TYPE_SCROLL_SENSITIVE));
         assertTrue("Supports scroll-sensitive ResultSets with updatable concurrency",
                    db.supportsResultSetConcurrency(ResultSet.CONCUR_UPDATABLE,
                                                    ResultSet.TYPE_SCROLL_SENSITIVE));

2. We were able to successfully scale solutions for X00,000 record queries that we 
page through in web app using these techniques.

3. It is certainly possible that the scrollable result set is implemented using a 
client side memory cache. But depending on size requirements you may still benefit 
from the approach????

Interesting...



> -----Original Message-----
> From: Andrew Gilbert 
> Sent: Tuesday, March 25, 2003 1:00 PM
> To: OJB Users List
> Subject: RE: Using setStartAtIndex with Oracle 8i
> 
> 
> Without commenting on the PB code, can say the scrolling 
> result set features work as expected on Oracle 8i. We have a 
> SQLIterator (akin to PB RsIterator) implemented using just 
> such techniques and it works well.
> 
> 
> > -----Original Message-----
> > From: Matthew Baird [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, March 25, 2003 12:40 PM
> > 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]

Reply via email to