IBM Support

Subassembly caching in Configurator and Visual Modeler

Troubleshooting


Problem

Subassembly caching in Configurator and Visual Modeler

Symptom

Subassembly caching in Configurator and Visual Modeler

Resolving The Problem

The Configurator caches models in memory for performance reasons. This document outlines how models are cached. All model data is stored in the database. When a model is compiled, model specific data from the DB is retrieved from the database and compiled into a runtime xml file. The runtime xml file has a time stamp associated with it which is the time when the model was compiled. When the configurator is invoked on the model by the end user, the following happens:

1.       The model cache is referred to. If the model is not found in the model cache it is loaded into the cache, please see below for model loading details.
·         If the model is found in memory the timestamps of the cached model and the runtime xml files are compared. If the runtime xml file has a more recent timestamp, the model in cache is flushed and the newly compiled model is loaded into cache
·         If the timestamps are the same, the model in the cache is used.
·         The steps below describe the process of reading the runtime xml file and caching the model
2.       The compiled xml file is parsed and the model construction begins.
3.       When the parser sees that a node in the model refers to a subassembly (OptionClassSubAssembly (OCSA), OptionItemSubAssembly(OISA), Model), the model cache is looked up to get an in memory copy of the subassembly.
    • If the subassembly is found in the model cache it is cloned in the parent model structure
    • If the subassembly is not found in the model cache it is loaded into the model cache using the same process (recursively) and then it is cloned into the structure of the parent model.
TEST CASES
Two models and one OCSA are created. The OCSA from both models is referenced.
·         Scenario 1:
1.       Tested Model1 and Model2. This ensures models are both loaded in the cache.
2.       Modified OCSA, saved the changes.
3.       Modified Model1, saved the changes and compiled Model1.
4.       Compiled Model2 (note no changes to Model2).
5.       Tested Model1. Changes to Model1 and the OCSA are rendered in the UI.
6.       Tested Model2. Changes to the OCSA are not rendered in the UI.
 
Conclusion: Since Model2 was compiled without any changes. The changes to the OCSA were not picked up.
 
·         Scenario 2:
1.       Changed OCSA and Model1 to its original state, saved the changes.
2.       Compiled both Model1 and Model2.
3.       Cleared the cache. The cache is now empty.
4.       Modified the OCSA, saved the changes.
5.       Modified Model1, saved the changes and compiled Model1.
6.       Compiled Model2 (note no changes to Model2).
7.       Tested Model1. Changes to Model1 and OCSA are rendered in the UI.
8.       Tested Model2. Changes to the OCSA are rendered in the UI.
 
Conclusion: Since the cache was cleared, Model2 was loaded into cache when it was tested and hence changes to the OCSA were picked up.
 
·         Scenario 3:
1.       Changed the OCSA and Model1 to its original state, saved the changes,
2.       Compiled Model1, Model2 and the OCSA.
3.       Cleared the cache. The cache is now empty.
4.       Tested Model1 and Model2. This loads Model1 and Model2 into the cache.
5.       Modified the OCSA, saved the changes, compiled the OCSA.
6.       Modified Model1, saved the changes and compiled Model1.
7.       Compiled Model2 (note no changes to Model2).
8.       Tested Model1. Changes to Model1 and the OCSA are rendered in the UI.
9.       Tested Model2. Changes to the OCSA are not rendered in the UI.
 
Conclusion: Since Model2 was compiled without any changes and since it was already in the cache. The changes to the OCSA were not picked up.
 
·         Scenario 4:
1.       Changed the OCSA and Model1 to its original state, saved the changes,
2.       Compiled both Model1 and Model2.
3.       Cleared the cache. The cache is now empty.
4.       Modified the OCSA and saved the changes.
5.       Modified Model1, saved the changes and compiled Model1.
6.       Compiled Model2 (note no changes to Model2).
7.       Tested Model1. Changes to Model1 and OCSA are rendered in the UI.
8.       Tested Model2. Changes to the OCSA are rendered in the UI.
 
Conclusion: Since the cache was cleared, model2 was loaded into cache when it was tested in item 8 above and hence changes to the OCSA were picked up.
 
·         Scenario 5:
1.       Changed the OCSA and Model1 to its original state, and saved the changes.
2.       Compiled both Model1 and Model2.
3.       Cleared the cache. The cache is now empty.
4.       Tested Model1 and Model2. This loads Model1 and Model2 into the cache.
5.       Modified the OCSA and saved the changes.
6.       Modified Model1 and saved the changes.
7.       Performed a Compile All.
8.       Tested Model1. Changes to Model1 and the OCSA are rendered in the UI.
9.       Tested Model2. Changes to the OCSA are not rendered in the UI.
 
Conclusion: Since Model2 was compiled without any changes. The changes to the OCSA were not picked up.
 
·         Scenario 6:
1.       Changed the OCSA and Model1 to its original state, and saved the changes.
2.       Compiled both Model1 and Model2.
3.       Cleared the cache. The cache is now empty.
4.       Modified the OCSA and saved the changes.
5.       Modified Model1 and saved the changes.
6.       Performed a Compile All.
7.       Tested Model1. Changes to Model1 and the OCSA are rendered in the UI.
8.       Tested Model2. Changes to the OCSA are rendered in the UI.
 
Conclusion: Since the cache was cleared, Model2 was loaded into cache when it was tested in item 8 above and hence changes to the OCSA were picked up.
When in doubt, compile all and clear the cache.

[{"Product":{"code":"SS6PEW","label":"IBM Sterling Order Management"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Component":"MCS","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All","Edition":"","Line of Business":{"code":"LOB59","label":"Sustainability Software"}},{"Product":{"code":"SS6PEW","label":"IBM Sterling Order Management"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Component":"MCS - Pricing","Platform":[{"code":"","label":""}],"Version":"","Edition":"","Line of Business":{"code":"LOB59","label":"Sustainability Software"}}]

Historical Number

NFX3145

Product Synonym

[<p><b>]Severity[</b><p>];Normal

Document Information

Modified date:
16 June 2018

UID

swg21553471