In order to understand what « cache » exactly is, we need to go back to the separation between the Designer and the Configurator.

Indeed, the Designer is the modeling environment allowing you to design and build Configuration Processes. Once a Configuration Process has been built (partially or completely), the Designer has stored all that design information in its database.

The Configurator is the run-time environment which will instantiate a Configuration Process whenever it is called by a user. This basically means that the CPQ Engine will look up the associated model in the database, and that it will load it into memory.

If the database model would be loaded into memory for each user, this instantiation would be very resource-consuming. This situation can be represented as follows:

In this situation, every user would have its own session in JBoss. Every session is built by a lookup in the CPQ database. In terms of performance, this would not be an optimal situation. Indeed, when the 3 users try to run the Configuration Process cpA, the necessary data will be loaded from the database 3 times, using the arrows (1), (2) and (3).

In reality however, things are much more optimized. With CPQ, the JBoss application server will use a part of its memory to put in place a central cache. This central cache will be used to load the model, which is coming from the database.

In this case, when users 1, 2 and 3 want to run the Configuration Process “cpA”, the following will happen:

• (1) The first user session will look into the central cache in order to see if the model for cpA is available. As it is not (yet), it will look the model data up in the database (2).
  • Once the model data have been retrieved, they will be used to fill up a central cache (3).
  • The second and third user session will look into the central cache again (4) and (5).

The figure above shows, in a simplified way, that a central cache will be beneficial to all sessions that issue requests for objects that are already available in the central JBoss cache

This central cache is thus beneficial once it has been loaded with all the necessary information. Of course, whenever a new version has been created in the development environment, and validated in the test environment, it will have to be published as soon as possible. This is important because the time needed to (1) design a new model or update existent models and (2) deploy those models in a production environment needs to be as low as possible.

In order to speed up that deployment time, a database cache has been put in place. This database cache will store a serialized version of the corresponding objects. This database cache can be generated, on demand, by a the Designer user (or via the API’s):

In order to accelerate version deployment, the following steps will have to be undertaken:

1. Whenever the new version has been created in the production environment, the database cache needs to be generated.
2. Whenever the first user accesses the central cache it will again find an empty cache. Therefore, it will tackle the database. However, instead of looking up the objects in the repository, it will look them up in the database cache (2).
   • Once the objects have been found in the database cache, they will be retrieved and stored in

     the central cache. However, this step is now much faster than before (compared to the situation without database cache) because the database cache holds the objects in such a way that it is very easy for them to be generated in the central cache. Therefore, step (3) is much “shorter” then before.

   • Once the objects are available in the central cache again, users (4) and (5) will again be able to access the central cache.
     Tip: In order to optimize version deployment time, it is recommended to activate the database cache.
     Warning: Generating the database cache, if used, will approximately double the size of the database space used by CPQ.

     Do Not: The generated database cache cannot be exported and/or imported by the CPQ Version deployment process.

     Warning: As the database cache generation is a resource-intensive process, it may be necessary to dedicate one or multiple servers to this task.