J2EE Blueprints Design Pattern
Paged List

 name

Paged List

 abstract

Make large, remote collections efficiently traversable by accessing the collection elements in pages.

 intent

Access remote collections in a network-efficient way

 category

Object Structural

 motivation

Distributed database applications often require the user to choose from a arbitrarily-long list of items. The client is only capable of presenting a sublist of the whole list at anyone time, and the user may be interested in only a small subset of the entire list. For example, in the Java Pet Store sample application, the JSP page product.jsp uses a Paged List to access lists of catalog items. Transmitting the entire catalog as a list of objects to view would be extremely inefficient from the point of view of network traffic and latency. Very seldom is a user interested in looking at an entire catalog: users generally browse long lists in search of something specific. In many cases, the list being accessed is so large that it's not even realistic to have the entire list in memory on the server at once.

The Paged List pattern provides a way to present a paged, scrolling list of items to the user, while minimizing network traffic, server load, and latency. Instead of receiving the entire list, the client code accesses a "ListChunk", a sorted list of items of a given length, starting at a given index. Instead of transmitting the entire list, the server-side implementation simply queries the catalog and returns the appropriate number of items, starting in the appropriate place.


 applicability

Use the Paged List pattern:

  • to display the result of the query
  • to present sublists of a large list of items to the user
  • when list length is too long to transmit to the client in its entirety, or when the full list is unnecessary

 structure

Figure 1. UML Diagram for the Paged List.

 participants

ClientView

  • displays long list of items to the user
PagedListInterface

  • abstracts access to sublist of virtual list on the server
PagedList

  • abstracts implementation of an individual list
  • provides access to sublists of the virtual list being browsed
  • must be Serializable
Model

  • abstracts access method for sublist request
enterprise bean

  • accesses database to produce requested sublist

 collaborations

ClientView

  • fetches sublist from Model, based on user actions
  • displays sublist to user
PagedListInterface

  • abstracts access to a PagedList object
PagedList

  • encapsulates a sublist of a particular type
  • result set type of Model's sublist method(s)
  • despite its name, does not implement PagedListInterface, but rather is the return type of the PagedListInterface method that accesses a sublist
Model

  • receives sublist requests from ClientView
  • forwards requests to enterprise bean
enterprise bean

  • receives sublist requests from Model
  • acquire sublist from database and transmit to Model

 consequences

  • Efficient access to large lists on the server. Clients can present "windows" on large lists present in the database, without needing to upload all of the information in the list.

  • Potentially higher number of server hits. Since the entire list of data are not been transmitted in a single request, each list browse results in a potentially large number of sublist requests.


 implementation-issues

  • Trade-off between network transmission load and server hit frequency. Smaller sublists result in a higher number of smaller server requests, as users browse through the large virtual list on the server. If the sublist size is too small, users will do more paging, resulting in a larger average number of remote calls. Larger sublists require more network data transmission, but result in fewer accesses. The client's list display capacity defines the upper limit of sublist size.

    With a fast network, it's usually better to fetch the largest list practical for the display device, to increase the chance the user will find what's being sought. A slow network, however, makes smaller lists preferable, since the overhead for transmitting a larger lists results in more latency and user frustration.

  • Sublist size may be client-dependent. Clients may differ in their list-display capacities, maybe due to display limitations, network bandwidth, or other factors unknown at deploy time. Ideally, the client should be able to indicate to the Model how many items it requires.

  • Caching can improve user experience and a decrease network load. If the client-side implementation of the PagedListInterface caches the result sublists, subsequent accesses to the list can be retrieved from a cache, instead of the network. The cache may need automatically to limit its own size (for example, using a high-watermark scheme to delete the least-recently-used entries.) This technique assumes either relatively stable data on the server (so the cache is never out of date with server data), or an active cache that can receive updates from the model when server data is modified.


 sample-code

Paged List is implemented in the Java Pet Store by the class ListChunk.java

The ListChunk class is used by, among other classes, CatalogDAO.java


 known-uses

In the Java Pet Store, the Catalog component uses Paged List to display the results of a user search, to list product categories, and to browse products from the catalog.

 related-patterns

Iterator