> In the web view, my page will use some sort of "pager" tag library. In
my
> Session Facade, I could just have a method which returns a Collection of
all
> the objects, and have the web interface logic just return a portion of
that
> list. I think I can do better than that, however. The Session method to
> return the list could take a "starting position" and "length", although
it's
> likely that the implementation of the method would still retrieve all the
rows
> from the DB, then return a portion to the Session Bean client.
Why retrieve all rows from the database? As a general solution, this is
vulnerable to the "large amount of data" problem. If you wind up with large
result sets, you'll be wasting a lot of memory and CPU cycles fetching and
materializing data that is never used. Under the worst case scenario,
you'll have users complaining about performance or the system will run out
of memory and crash.
My preference is to use an API like this:
Page fetch(Criteria criteria,
Direction direction,
int position,
int maxrows)
For example, to start at the beginning of the list, reading only 25 rows,
I'd call fetch(Direction.FORWARD, criteria, 1, 25). To get the next page,
call fetch(Direction.FORWARD, criteria, 26, 25).
In the implementation at the JDBC layer, you can use a scrollable result
set (with the absolute() and/or relative() methods) to jump to the right
position. Then use next() or previous() to read only the rows you need.
This way, you read only the data you need. And you avoid unnecessarily
materializing many objects that you may never use.
I have used a modified version of this (page by page iterator) pattern
before, with great success.
-eric
"David M. Karr" To: [EMAIL PROTECTED]
<dmkarr@EARTHLINK cc:
.NET> Subject: Design advice: Support for
pageable views
Sent by: A in Session/Entity APIs
mailing list for
Enterprise
JavaBeans
development
<EJB-INTEREST@JAV
A.SUN.COM>
06/18/2002 03:49
PM
Please respond to
"David M. Karr"
I'm in the midst of designing the EJB portion of a small J2EE application.
I'd
like to properly design the API to support "pageable views" of a list of
objects. I'm interested in advice on how best to design this interface.
In the web view, my page will use some sort of "pager" tag library. In my
Session Facade, I could just have a method which returns a Collection of
all
the objects, and have the web interface logic just return a portion of that
list. I think I can do better than that, however. The Session method to
return the list could take a "starting position" and "length", although
it's
likely that the implementation of the method would still retrieve all the
rows
from the DB, then return a portion to the Session Bean client.
Figuring out the correct "starting position" bothers me a bit, though.
This
could have problems if rows were inserted/deleted while the user was paging
through the list.
I guess this might be a reasonable application of a Stateful Session Bean,
but
this has different tradeoffs from the alternative. If I use a SFSB, I
could
store the ResultSet (or some form of it) in the SFSB, which would not
reflect
inserts/deletes while the user was paging through the list. This would be
both
a good and a bad thing. It would make paging back and forth through the
list
more repeatable, but it would then allow for the possibility of drilling
down
from an entry in that list to an entry that had just been deleted, although
I'd
probably have to check for that no matter how I implemented paging.
--
===================================================================
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
===========================================================================
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".
