An enhancement to what you've described would be a query like this:
SELECT TOP :pagesize * FROM table WHERE NOT IN (SELECT TOP :pagesize*page *
FROM table)
where pagesize is the number of rows per page
and page is the zero based number of the page
this works fine with SQL Server, and I think there's an equivalent in Oracle
8i which uses
keywords ROWNUM and EXISTS(tough you can use IN, EXISTS seems to be more
efficient). This is
an approach we've used succesfully in several projects for pagination. With
BMP, instead of
querying for all the fields, we just query for the PK's (whether composed or
not), and inflate
Entity Beans from there on :
Collection.add( EBHome.findByPK(PK) );
With this approach, you JIT use the DB conn, and with most DBs today,
this is what performs best(tough, of course, many may say that in some
cases caching would be useful).
Hopefully, EQL or whatever it'll be called will provide some of this
functionality
that enables simple, scalable solution for some problems that right now,
look nasty
for many of us (if you don't believe me, check the archives, and you'll be
amazed about
the number of posts regarding pagination and data caching alone).
-----Original Message-----
From: Gary Windham [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 28, 2000 4:02 PM
To: [EMAIL PROTECTED]
Subject: Re: Statefull session bean to handle queries
This is an interesting problem that I've been wrestling with in the context
of master-detail lists. I have a "master list view" in our application that
is implemented as pages, which can be navigated sequentially or randomly.
My current approach is to use a stateless session bean which performs a JDBC
query using a "SELECT TOP ..." statement and then cursoring through the
resultset (e.g., if a page size is 20 rows, and you want the 5th page, you
use a "TOP 100", then cursor down 80 rows). Obviously this approach is
fraught with problems. I haven't been able to find an approach that is a
complete "win". Stateful session beans have scalability and resource
consumption problems. One approach that I've been investigating is using
"transient entity beans", which live only in the EJB object cache (see
http://www.c2.com/cgi/wiki?SearchResultAsEntityBean and
http://www.c2.com/cgi/wiki?TransientEntityBean). The risk here is that if
you have a large result set, and/or lots of client "think time" between
"chunk" retrievals, your entity bean could be flushed from the cache before
you're done with it...in which case you would have to re-execute your query.
--Gary
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Chris Brown
Sent: Friday, July 28, 2000 8:50 AM
To: [EMAIL PROTECTED]
Subject: Statefull session bean to handle queries
Has anyone had success with or have suggestions on the following?
Use a statefull session bean to handle queries from a client (servlet). The
statefull session bean will create and hold on to the resultset on behalf of
the client. The client controls the display of "result pages" to the user
and calls methods on the statefull session bean to move through the
resultset. The results are passed back to the client as a collection of
"state" objects. The servlet will store a handle to the session bean in the
session.
Concerns:
Is this the proper design?
How long is the statefull session bean tied to the client?
Passivate/Activate - will the resultset be serialized/deserialized properly?
Can it handle large result sets? 20,000+ rows?
Thanks in advance,
Chris
===========================================================================
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".
