Yes, an egregious faux pas on my part :-) Thanks a lot for pointing it out
;-)
RPS
> -----Original Message-----
> From: Chris Raber [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, April 18, 2000 4:20 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Paging large database result sets
>
> Randy,
>
> On #1 I think you meant Statefull Session Bean since this is state for
> that
> client, oui?
>
> -Chris.
>
> PS: Can you imagine correcting a colleague over the internet? No egos at
> GemStone! ;-)
>
> > -----Original Message-----
> > From: Randy Stafford [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, April 18, 2000 4:33 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Paging large database result sets
> >
> > Jon-
> >
> > Yes, I think this is a common (but tough) problem. Your choices seem to
> > be:
> >
> > 1. Hold the ResultSet, Statement, etc. in stateless session bean state
> so
> > you can get the next batch of results. Undesirable because it holds
> onto
> > RDBMS resources. Plus extra work is required to navigate backwards
> (you'd
> > have to cache in stateless session bean state the results you'd already
> > navigated past).
> > 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.
> > 3. Read the whole result set and pre-create the corresponding HTML
> pages,
> > as
> > one respondant suggested. Desirablility a function of practicality in
> > your
> > app.
> > 4. Read the whole result set and cache it somehow. Downside is memory
> > consumption.
> > 5. Make the user refine his query to yield a smaller result set.
> >
> > etc., etc. Includes elements of the old space-time tradeoff. :-)
> >
> > 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.
> >
> > Best Regards,
> > Randy Stafford
> > Senior Architect
> > GemStone Professional Services
> >
> > > -----Original Message-----
> > > From: Jon Lee [SMTP:[EMAIL PROTECTED]]
> > > Sent: Tuesday, April 18, 2000 9:53 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Paging large database result sets
> > >
> > > Currently looking at the best way to deal with http requests for
> result
> > > sets obtained from an SQL (DB2 AS400) database.
> > > I am using a stateful session bean to access this database.
> > > I am sure this must be a common issue.
> > > For example, a request effectively asks for a 500 row table to be
> > > returned.
> > > I want to return 50 of these rows in a response to the user, and then
> > give
> > > them the option of returning the next 50 or previous 50, etc.
> > >
> > > a) I can limit the number of rows being returned using setMaxSize()
> on
> > my
> > > prepared statement, but I am then unsure of how I can obtain the next
> > set
> > > of records, when requested, as JDBC does not seem to allow me to do
> this
> > > (anyone know anything about this?)
> > >
> > > b) I can bring back the whole 500 row result set, store it on the
> > > StatefulSB as a cachedresultset(?) or as a Collection of some kind.
> > > Hopefully weblogic's container would effectively manage the memory use
> > > that this would involve, but I would save myself trips to the database
> > > (offsite).
> > >
> > > This must have been solved many times before, what do people think?
> > >
> > >
> >
> ==========================================================================
> > > =
> > > 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".
>
> ==========================================================================
> =
> 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".
