InfoCenter Home >
4: Developing applications >
4.5: Dynamic fragment cache >
4.5.3:   Dynamic fragment cache frequently asked questions

4.5.3:   Dynamic fragment cache frequently asked questions

View frequntly asked questions related to:


General cache information

  • Question:  What is new in dynamic fragment cache WebSphere Application Server version 4.0?

    Answer:  Version 4.0 allows you to configure dynamic cache through the GUI. The administrative console offers parallel configuration options to the dynacache.xml file. Cache policies can be attached to .war files using the Application Assembly Tool. While XML adds some advanced cache policy options, the AAT makes cache policies portable, by installing them along with the application.

  • The Servlet Cache Monitor is also new in version 4.0. This Web application installs on an application server, and allows administrators to inspect the contents of the fragment cache.

    Finally, the APIs for programmatically manipulating the cache have been enhanced. These APIs are located in the com.ibm.websphere.servlet.cache package, and contain classes and methods to customize cache operations.

  • Question:  What are the security implications of using the fragment cache?

    Answer:  The cache does all the processing within the Web container after the security processing completes. Within the application server, there are no extra security problems to be considered.

    When using an external cache, security risks change dramatically. Caches outside of WebSphere Application Server do not undergo security processing. It is important not to store sensitive data in an external cache.

Return

Cache architecture

  • Question:  What type of servlets and JSP files does the cache support most effectively, simple presentation JSP files? What about servlets that use enterprise java beans or JDBC? What about personalized fragments?

    Answer:  While caching a simple presentation JSP file gives moderate performance gains, caching servlets that request information from enterprise java beans or databases saves WebSphere Application Server processing power, and decreases load on the back end. You should cache fragments that pull information from outside WebSphere Application Server since the biggest performance gains come from caching servlets that obtain information from outside the application server.

    Personalized information can be cached, though how effective it will be depends on the architecture of the application. See the Dynamic fragment cache XML examples for a discussion of personalization.

  • Question:  The dynamic cache caches the JSP and servlet output. Does this mean it caches the HttpServletResponse object?

    Answer:  Not quite. It caches the output of the servlet (what is written to the response.getWriter method, for example). It also caches side effects of the servlet's execution, like setting cookies and headers, including and forwarding other servlets, and setting content type and character encoding.

  • Question:  Is this an "in memory" cache, or an "on disk" cache? Does it use the java heap?

    Answer:  The cache resides completely inside the Java heap. This keeps it in memory, but allows it to use virtual memory if necessary.

  • Question:  Does the dynamic cache always need an external cache for caching?

    Answer:  The dynamic cache does not require an external cache to be present for caching. It will, however, extend the abilities of such static caches to include caching certain servlets and JSP files.

  • Question:  If using an external cache that is associated with the dynamic cache (for private user information), how is the security of the information at the external cache enforced?

    Answer:  Because private information almost always involves session information, requests for private user information are usually not externally cacheable. However, in the case of a user id being present in the URL, or of pages that should only be accessible over HTTPS and not HTTP, external caching can short circuit the authentication or encryption processes. For sensitive information, external caching is not the best choice unless specific measures are taken, such as encrypting that user id.

Return

Application design

  • Question:  My application has a control servlet that works as a dispatcher for 10 other services, and we only want to cache the output of one or two services from this servlet. Is this servlet cacheable?

    Answer:  Definitely. Cache policies can be built to "cache" or "not cache" a servlet depending on whether input variables are present or have a specific value. Therefore, you can "cache" the control servlet when it is performing some read only action, and "not cache" it when it is updating application information. In addition, if the cache policy rules are not specific enough for the caching you want to perform, WebSphere Application Server provides a pluggable interface for writing your own Id Generators. See the Custom Generators article for more information.

  • Question:  If I have a chain of forwards or includes, can I cache some of the fragments and not others? If one cached fragment in the chain is invalidated, do the rest of them get evicted from the cache, too?

    Answer:  Any of the servlets or JSP files in the chain can be cached. If some or all of them are cached, and one changes (invalidating only its cache entry) then the output of upstream, cached servlets will reflect this change. Cached servlets have 'place holders' in their output for the results of any includes or forwards that servlets might perform.

Return

Cache configuration

  • Question:  I have existing XML configuration files from WebSphere Application Server version 3.5.x that I would like to use. Are they still valid?

    Answer:  Yes. Dynacache.xml and servletcache.xml files from version 3.5.x will work with version 4.0

  • Question:  How can I tell whether the cache is enabled?

    Answer:  Check the standard output file for the application server that you configured. You will see a message indicating whether the cache is enabled or not. Alternatively, use the servlet cache monitor to inspect the fragment cache.

  • Question:   Is there a way to know whether a fragment is getting cached?

    Answer:  After executing the servlet or JSP file, you can check for the presence of an entry in the cache using the servlet cache monitor. See article Dynamic fragment cache monitor for more information on this tool.

  • Question:  How big should my cache be?

    Answer:  Cache sizes should typically stay in the 1-10K entries range. Ideally, the cache should be big enough to contain an entry for each invocation of the fragments to be cached. More likely you will make the cache big enough to hold the most expensive and most often served fragments, and use the LRU algorithm to elimate less useful quotes. The capacity can only be measured in number of entries, not in memory size. Increase the memory available to WebSphere Application Server according to the size and number of cached responses.

  • Question:   Can I use cache policies defined in a servletcache.xml file and policies attached to an .ear or .war file on the same server?

    Answer:   Yes. In the case of a URI being defined in both, the XML file takes precedence.

  • Question:   I do not understand how the <invalidateonly/> tag works. Aren't the invalidate and exclude rules enough to invalidate a cache entry?

    Answer:   While the methods in the Cache class are sufficient for manipulating cache entries, users are not required to implement any java code to enable caching The <invalidate> and <invalidateonly> tags extend the capabilities of rule based XML configuration to more completely cover the operations you can perform when using the API directly.

    The <invalidate> element allows you to use a fragment invocation to invalidate other cache entries The classic example is a "buy" servlet that adds objects to a shopping cart. Whenever you perform a buy, you would then invalidate the cache entry for that user's shopping cart.

    The <invalidateonly/> element exists for efficiency. Some servlets may not be cacheable, but have invalidation side effects. With this tag, WebSphere Application Server performs the invalidations, but does not attempt to cache the servlet. (The caching attempt would have failed, anyway.)

Return

Go to previous article: External caching Go to next article: Java Technologies

 

 
Go to previous article: External caching Go to next article: Java Technologies