The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

import-bot (20211) [Avatar] Offline
#1
[Originally posted by rstinejr]

For paging through large tables, we've found the following to be pretty
effective: rather than relying on non-standard SQL to return selected rows
from a table (section 4.3.3, p. 104), we use SQL or EJB QL to return a
Collection of all the entity bean primary keys. Then, when the user requests
a page, we get the bean instances (and perhaps construct DTOs) necessary for
populating it. This is a variety of lazy evaluation.

Having a Collection of primary keys also solves the number of pages/number of
instances problem mentioned in Section 4.3.7.

The problem is messier if you want to give the user the ability to sort or
resort on various keys -- you would either need separate queries for each
sort order (yuck!), or you could define an object that included sort tags with
PKs (easier to do with JDBC than EJB..)
import-bot (20211) [Avatar] Offline
#2
Re: Eager Iterator comment (4.3.3)
[Originally posted by crazybob]

> For paging through large tables, we've found the following to be pretty
> effective: rather than relying on non-standard SQL to return selected rows
> from a table (section 4.3.3, p. 104), we use SQL or EJB QL to return a
> Collection of all the entity bean primary keys. Then, when the user requests
> a page, we get the bean instances (and perhaps construct DTOs) necessary for
> populating it. This is a variety of lazy evaluation.

I've often found that transferring the data over the wire is a limiting
factor. If you can afford to transfer
all of the primary keys over, re-execute the real query and transfer all of
that data over, than yes, this
is a viable solution.

As page by page iterators are read only and memory intensive, I'd normally use
direct access rather
than EJBs. I like to use Hibernate, Castor, or something comparable, in which
case the vendor-specific
SQL is oftentimes already abstracted away for you.

> The problem is messier if you want to give the user the ability to sort or
> resort on various keys -- you would either need separate queries for each
> sort order (yuck!), or you could define an object that included sort tags with
> PKs (easier to do with JDBC than EJB..)

Now you have session state in the application server. In practice, I've often
found rerunning the query
to be a more scaleable option.