> > > 2. Keep in conversational state the ids of the first and last rows the
> user
> > > is currently looking at, and re-issue the query every time he navigates.
> > > Undesirable because of extra computation, plus gets complex if there is
> > > sorting & grouping going on, or the table changes out from under the user.
>
> >
> > No good as Randy explains.
> >
> > > 5. Make the user refine his query to yield a smaller result set.
> >
> > Not practical or user-friendly.
> >
> > > In the FoodSmart example application on the Developer's Guide CD
> > > (http://www.gemstone.com/javasuccess), the way we handle this is to read
> the
> > > whole result set and cache it in GemStone's PCA. Then we give a
> > > SearchResult entity bean back to the client, which allows random
> navigation
> > > through the result set. This is an example of the search result as entity
>
> > > bean pattern - see http://www.c2.com/cgi/wiki?SearchResultAsEntityBean.
> >
> > No good, this solution if wasting a lot of server resources.
> >
> [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.
> If the data being queried over doesn't persist in PCA, then yes,
> this solution involves O/R mapping and caching the result in PCA - which is
> probably not a good solution for very large tables.
This is our situation.
> > The average user does not really want to navigate around 100.000 rows, what
> we provide is
> > something like this:
> > + getCount(String) allows the client to submit a query
> > and returns a count of how many records fit that query
> > + getPage(String,int,int) allows the client to submit a query,
> > a starting position and a pagesize and returns a page of records
> >
> > This simple scheme fits nicely with Swing components such as JList,
> JTable...
> > A JList model will use "getCount" to answer the "getRowCount" question and
> > then "getPage" to answer the "getElement" question depending on the user
> > viewing area, no need to serialize the whole resultset or keep any state at
> the server.
> > The client caches 2-3 pages of data to allow the user for scrolling.
> > Usually the user makes a general query, sees how many thousands of records
> > fit the query, then redefines the query until he or she gets the right
> > data.
> >
> [Randy Stafford] So in effect, aren't you doing a combination of 2
> and 5, above - re-issuing the query and making the user refine his query,
> both of which you acknowledged as "no good"?
<embarrassement>Ups! It's true! </embarrassement>
Note 5 is no good on its own, 2+5 is what we are doing.
> > The client keeps the state, i.e. the client knows what query to perform
> > (including sorting and grouping etc) and also where to start and how many
> records
> > to get back.
>
> [Randy Stafford] In our solution the client keeps the state as
> well, in terms of where in the result set snapshot the user is currently
> navigating. Without a snapshot, how do you handle the case where the table
> changes out from under the user in between his navigations? Especially with
> sorting and grouping, this could result in a disconcerting user experience.
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, 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.
Anyway a serverside snapshot is not a solution for this problems either.
Sorting and grouping is performed on the server with each query.
If the resultset has less records than the pagesize then sorting can be
performed
on the client.
Regards
Javier
===========================================================================
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".
