This documentation supports the 9.1 version of Remedy Action Request System.

To view the latest version, select the version from the Product version menu.

About Mid Tier caching

The first time a form, view, or form and view combination is requested via BMC Remedy Mid Tier, performance can be impacted by the intensive processing necessary to obtain the form, field, active link, and associated information from BMC Remedy AR System server. This can be time consuming when there are large forms with many fields and many associated active links. It is also important that memory is not consumed for forms that are not accessed.

Also refer to the mid tier caching recommendations.


While you upgrade BMC Remedy Mid Tier, if the cache version number changes, the catalina.out file logs the following message, and BMC Remedy Mid Tier rebuilds the cache:

CACHE: SetupServlet:init: Version change is detected due.
Older version = 0 New version = 5 Cache has to be flushed and rebuild

To minimize the usability impact of this performance hit, the Mid Tier Configuration Tool includes the following configuration options:

  • Flush cache — Removes all items from the mid tier cache. When the objects are requested, the most up-to-date versions are retrieved from the BMC Remedy AR System server. For details about the Flush Cache feature, see Flush Cache.
  • Sync cache — Clears only objects that have changed on the server after the last cache clear event. In this case the mid-tier contacts BMC Remedy AR System server and compares the last-changed-timestamp on elements and synchronizes any changes. For details about this feature, see Using the sync cache option.


    -- The Sync cache option is not available for 7.1.0 and prior releases.

    -- When you restart BMC Remedy Mid-Tier (or Tomcat), it starts building views and performing sync cache operations to ensure that the cache contents are up-to-date. Loading those views in the cache takes time if there are a lot of AR System server views in the viewstats.dat statistics file, which subsequently delays the sync cache operation. During this period, if mid tier gets any request, it sends the older version of the requested data.

    As an administrator, you can check the sync status on the Cache Settings page to verify whether the sync was completed successfully.

  • Definition Change Check Interval — This mid tier cache setting is configured to set an interval (in seconds) at which information in the cache is updated. The default value is 86400 seconds. For details about the Definition Change Check Interval setting, see AR Server Settings.

Mid tier caching recommendations

Whom does this information benefit?

If you are using the caching recommendations developed on the prior design of mid tier's caching infrastructure you may be restricted in realizing the benefits of the new design. Use the information provided here if you are a user of:

  • version 7.5.00 patch 004 of AR System Mid-Tier
  • version 7.5.00 of AR Server any patch level or higher
  • version 7.1.0 of AR System  - except new Sync Cache feature

Recommended caching setup and procedures

  • Disable Mid-Tier Prefetch — Prefetch has always been a brute force approach to loading forms into memory based on a somewhat arbitrary list of forms configured in the prefetchConfig.xml file by the system administrator. Forms and other cache objects end up in memory, but are not actually ever used by end users wasting valuable memory space. To disable Prefetch, log on to the Mid-Tier Configuration tool, on the Cache Settings page, remove the contents of the prefetchConfig.xml file so only these elements remain and save changes:
<?xml version="1.0" encoding="UTF-8"?>
<midtier-prefetch-config&nbsp; xmlns="">
  • On the AR Server Settings page, ensure that the Perform check check box is selected. The Perform check check box activates the feature called Sync Cache that eliminates the need for administrators to flush the entire Mid-Tier cache after a form, active link, menu, etc. definition change on the AR System server. Mid-Tier now automatically synchronizes its cache for just the changed objects. It performs this check at the interval selected in the Definition Change Check Interval field. Or, an administrator can press the new Sync Cache button on the Cache Settings page to have the changes synchronized immediately. The Sync Cache operation, whether done automatically via Perform check interval or by pressing the Sync Cache button for the AR System server, synchronizes any of the following objects whose last changed timestamp is newer on the AR System server than in the current mid tier cache: Forms, Active Links, Containers (such as Guides, Applications, Web services, etc.), and Menus (Character menus). Sync Cache completely removes and rebuilds the following cache items since the performance hit is minimal: Group data, Role data, and Image objects.
  • On the AR Server Settings page in the Mid Tier Configuration tool, enable the new feature, Preload, by selecting the check box. Preload will, on a restart of mid tier, load all Active Links and Menus to the disk cache and any form which is user facing, that is, any form which has an Active Link associated with it.
  • Select the Enable Cache Persistence check box.
  • Save changes to the AR Server Settings.
  • Shutdown the JSP engine. Remove the contents of mid tier's /cache and /cachetemp directories and start the JSP engine.
  • Allow Preload to complete processing.
  • Allow end users access to the system. BMC recommends allowing at least 1-2 days of normal end user usage of the system. This type of activity is desired because mid tier updates a statistics file of what forms and views the users are accessing. This statistics file, viewstats.dat, tracks which forms/view combinations are being accessed, which group combinations are accessing, and how many hits each has.


    The viewstats.dat statistics file is not related to the cache (ehcache) statistics (see About the cache table). The viewstats.dat file is based on user activity and is not dependent on any configuration.

  • After 1-2 days of usage, disable Preload using the Mid Tier Configuration tool, by deselecting the check box on the AR Server Settings page.
  • Stop the JSP engine.
  • Start the JSP engine. With Prefetch and Preload disabled, the mid tier, upon startup, use its statistics file to quickly load up into memory from the disk cache, only forms which users have been accessing. This allows for the most efficient use of mid tier's in memory cache and the best form access performance for end users.
Was this page helpful? Yes No Submitting... Thank you


  1. Stefan Hall

    Can you explain the working of Perform Check, Cache Persistence and Preload in servergroup configuration such as 2 ARS with LB.

    My understanding is

    - set Preload only for LB
    - set Perform Check for LB, but what about the two ARS behind LB
    - set Cache Persistence for LB, but what about the two ARS behind LB

    Should I activate the three Options for all three server entries or only for the LB?

    Thanks in advance

    Jun 02, 2016 01:52
    1. Prachi Kalyani

      Hello Stefan,

      I will get this verified and update you soon.



      Jun 02, 2016 06:49
    1. Prachi Kalyani

      Hello Stefan,

      In Midtier 9.1, preload and perform check are set for each server defined to the midtier. Persistent cache is set for the entire cache (across all defined AR System servers).

      The purpose of preload is to load the meta-data to midtier memory for the specified AR Server. This activity is the most resource intensive action of the caching process. Preload allows you to take that resource need before the users start using the midtier. Thus, you would only want to do preload on the loadbalancer server as that is what your user community will use.   

      Perform check will do what the Sync Cache button does on a regular specified interval.   Basically, it takes inventory of the midtier cache contents for the specified server, compares the date or timestamp of the cached object compared to the AR System server, generates a list that needs to be update, clears those items from cache and then re-caches them.

      Note:  The Sync Cache button is only available when Perform Check is enabled. This should be set for all servers defined to the midtier and is independent of whether preload is enabled or not.

      Cache Persistence writes the compiled cached objects from midtier memory to disk. If a particular object is not used and cache management moves it out of memory, the next request for that object can be quickly pulled from disk and placed back into memory. The alternative is the meta-data would be retrieved from the AR System server, compile with the appropriate javascript and resource files and then placed into memory for the user to access. This is more resource intensive and will be time-consuming. Cache Persistence is set for the midtier and affects all objects cached for each of the defined servers.



      Jun 03, 2016 05:36
  2. Stefan Hall

    Hello Prachi,

    wow, thank you very much for your detailed explanation. Now it's cler to me.

    Warm Regards

    Jun 03, 2016 01:47
  3. Sandeep Das

    I performed a fresh installation of Remedy 9.1.02 and am unable to find the prefetch.xml under Cache Settings on the Mid-Tier Configuration Page. Can you please confirm if the prefetch.xml feature applies to 9.1.02?

    Mar 27, 2017 12:43
  4. Daniele Conigliaro

    Hi Prachi, I have one question of general interest (I think). Every documentation I find recommends to enable pre-load after midtier cache flush, to keep it enabled for a couple of days and then disable it, so that viewstats.dat can be used. Why do we need to enable Preload? Are statistics (viewstats.dat) not populated if preload is not enabled? As far as I can see viewstats gets populated even if preload is disabled, so I'm always wondering why are the two things (preload and statistics) related. I understand that with a good viewstats.dat, after restart (without preload) memory will be filled up with cache only with the useful objects. But I don't understand what's the advantage of enabling preload. Thanks

    Oct 06, 2017 10:00
    1. Anagha Deshpande

      Hello Daniele,

      Thanks for raising this concern. I will discuss this with the SME and will write back to you.



      Oct 08, 2017 09:53
    1. Anagha Deshpande

      Hello Daniele,

      Apologies for a delayed response.

      The advantage of preload is:

      When the Preload Tables Configuration option is on, the server uses multiple threads running in parallel (preload threads) to load data in segments from database tables into memory.



      Jun 25, 2018 01:32
      1. Uli Rogosch

        Are there any downsides from keeping the preload option activated all the time, besides a slow restart of the midtier (i.e. is viewstats.dat never used in that case) ?

        Does this also apply to a highly customized application that is in constant development?

        Mar 13, 2019 06:04
        1. Anagha Deshpande

          Hello Uli,

          We are working on your query.

          We will respond soon.



          Mar 13, 2019 09:54
          1. Anagha Deshpande

            Hello Uli,

            You need to enable the Preload option only when you build the Mid Tire cache for the first time.

            You must disable the Preload option before restarting the Mid Tier. When you restart the Mid Tier, the Viewstats.dat utility caches the required objects in the in-memory cache and the Mid Tier memory footprints are optimized.

            Hope this helps.



            Mar 19, 2019 01:19
  5. Yang Sun

    For Sync Cache option, this would starts based on Perform Check Interval or pressing Sync cache button in MidTier config tool.

    Is there any way to set starting time for Sync cache, it will start based on user requirement.


    Yang Sun

    Oct 17, 2017 02:25