In most cases the decision for data currency is a

  • No School
  • AA 1
  • ghitaarab
  • 672

This preview shows page 373 - 375 out of 672 pages.

data. In most cases, the decision for data currency is a business decision. Multiple methods are available to configure data caching: Keep a local copy in a database within the same network realm as the application Cache data from a localized database in memory to minimize database reads Use EJB persistence to keep the data in the memory space of the running application Sometimes data is provided by an external provider. Making live calls to these data can prove to be a SPOF and a slower performer. If no strict dependencies are on the currency of the data, offloading these data to a local database can provide large performance, availability, and scalability gains. The data can be refreshed periodically, preferably during off-peak hours for the application. Database data caching To minimize direct reads from the database, database systems usually offer one or more of the following options: Fetch-ahead constructs attempt to anticipate that more pages from that table are required and then preload those pages into memory pools. Buffer pools keep data loaded into memory, assuming that it is likely the same data will be requested again. Both of these constructs reduce disk access, opting instead for reading the data from the memory, increasing performance. These facilities assume that the data is predominately read-only. If the data has been written, the copy in memory can be stale, depending on the write implementation of the database. Also, memory buffers can be used to store data pages, reducing disk access. The key is to make sure that the system has enough memory to provide to the database. The database also takes advantages of the storage cache to avoid physical disk access. Application data caching Another option is to cache some of the database or web page data inside an application. You can do so by creating objects that are instantiated when the application server is started. Those objects pull the necessary information in memory, improving performance because the query is against an object in memory. Ensure that some synchronous or asynchronous mechanism (or both) is available to update this cache on a timely basis according to the system requirements. However, this approach can create more memory requirements, especially if a dynamic cache that might grow over time is implemented. EJB persistence implies loading the data into an EJB after a call to the data provider. This method is similar to database caching, except that caching takes place in the application space, not in the database server memory. The EJB has an access intent, which indicates the rules that are used to determine the currency of the data in the bean. From a performance standpoint, avoiding a call to an external database in favor of a local bean creates significant gains.
Image of page 373
348 WebSphere Application Server V8.5 Concepts, Planning, and Design Guide 10.8 Session management This section introduces the session management concept and explains how you can manage the sessions with WebSphere Application Server.
Image of page 374
Image of page 375

You've reached the end of your free preview.

Want to read all 672 pages?

  • Fall '19
  • Wind, Web server, IBM WebSphere Application Server, IBM WebSphere, IBM Software, IBM WebSphere Application Server Community Edition

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture