Not to take away from PCA (GS/J can no doubt cache big results sets,
etc...), however, in a case where the result set is that big, I would
probably not do that. No silver bullets if the result set is this huge.
Better to return a subset in the first invocation of the query, and then on
the next invocation return the next chunk etc... It's not elegant but for
something of this scale it is more practical.
Or prompt the user for a more practical filter! What the heck is the client
going to do with a 100,000 records anyway? !!!
-Chris.
> -----Original Message-----
> From: Randy Stafford [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, April 26, 2000 1:52 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Paging large database result sets
>
> Javier Borrajo wrote:
>
> > > [Randy Stafford] If the data being queried over is already
> > > persistent in PCA, this does not waste any resources - it merely
> results
> > in
> > > the creation of a Collection whose elements are pointer references to
> > > objects already persistent in the object database, and an entity bean
> to
> > > wrap that collection, that implements behavior similar to what you
> > describe
> > > below.
> >
> > I have a lot of difficulty visualizing how to efficiently cache
> resultsets
> > with
> > 100.000+ rows. For example we have a table with customer data that has
> > over 2 million rows. We allow the user to query this table to find
> > customers.
> > The user interface includes several controls and a JList. The user can
> use
> > the controls to compose a lot of different querys. I don't see how
> server
> > side
> > caching can help here.
> >
> [Randy Stafford] GemStone's cache (PCA) is an OODBMS - not a
> volatile in-VM-memory cache. So there could be a collection of two
> million
> customer objects persisting in the OODBMS, if that's where you choose to
> persist them. In our approach a query over such a collection would result
> in the creation of another, smaller, collection (to hold the query
> results),
> whose elements are simply pointer references to the customer objects
> already
> persistent in the OODBMS. The result collection is also committed to the
> OODBMS, and wrapped by an entity bean distributed to the client (OODBMSes
> do
> have their advantages). If the customer objects' state is instead stored
> in
> an RDBMS, then I agree that O/R mapping all the customer objects that form
> a
> large result set, and committing the mapped objects to the OODBMS, would
> not
> be the optimal solution. Your approach seems like the best balance one
> could hope for in that situation.
>
> > The client caches pages of data. We do not use a server side snapshot.
> > Each page is the result of a new query, so the data is up to date when
> the
> > user
> > scrolls down the JList/JTable or presses the "Find" button
> >
> [Randy Stafford] Sounds like a good optimization.
>
> > , but there is no
> > garantee the
> > data *stays* current on the client cache.
> > There are 2 kinds of querys:
> > 1. when the user presses the "Find" button
> > 2. when the user scrolls down with a JList or a JTable
> > In the first case the client performs both "getCount" and "getPage".
> > In the second case the client only performs a "getPage".
> > Problems:
> > A. the number of records that fit the original query changes
> > B. client side cached records change in the server
> >
> > Both problems exist with our scheme, but we tolerate them.
> >
> [Randy Stafford] That's cool; sounds like you can tolerate the
> "don't care" semantics. Interesting discussion - thanks for sharing your
> solution!
>
>
> Best Regards,
> Randy Stafford
> Senior Architect
> GemStone Professional Services
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
