fcSDK Cache files: sometimes more trouble then they're worth
One of the features of the fcSDK is its ability to cache frequently-used, rarely-changed data, such as the schema meta-data (ADP tables), lists (Application Lists, Status codes, User-defined lists), geography data (states, countries, time_zones, currencies), configuration items, and strings.
When the fcSDK starts up, it reads all of this data from the database and saves it into memory. In addition, it writes out the data to cache files. The next time the fcSDK starts up, if there are cache files present, it loads the data from the cache files, as opposed to having to go to the database. This improves the performance of the loading of the cache data, as reading from a local file is quicker than loading from a remote database.
However, these cache files can often cause trouble. If a piece of cache data is changed in the database, this change is not immediately propagated to the fcSDK, or its cache files. There are methods for telling the fcSDK to update its cache, or you can simply delete the cache files and restart the application, which will re-create the cache files.
However, remembering to manually delete the cache files (and sometimes even finding where the cache files are) can be a challenge.
One scenario that we run into occasionally is that a customer tries to start up an application that uses the fcSDK (such as fcClient or RuleManager), only to be presented with an error regarding corrupt cache data. The DataVerifier application can be used to validate and help track down corrupt data in the database. Once the bad data is fixed, and the DataVerifier shows that all is well, the original application still won’t start. This is because the bad data has already been cached to files. And when the app starts up, it loads the data in from the files, not from the database. The "fix" is to find where the application put its cache files, manually delete them, and restart the app. This all works, but its kind of a PITA, and normally results in a support call.
Premature Optimization
All this cache file stuff seemed like a good idea at the time (over 5 years ago). We’ve learned a lot since then. 
We accounted for a performance problem that we didn’t have. No one complained that the startup time of fcSDK (or the original FCFL) was slow due to the time needed to cache data. We didn’t have this problem. But we implemented a solution. A solution for a problem that didn’t exist.
Note that I’m not saying that caching frequently used data in memory is bad. I still believe this is a good idea. I’m saying that the writing and reading of this data to files is where the trouble comes in.
Most of the applications that use the fcSDK tend to be long-running apps, meaning that they start up, and stay running for a long time. Web applications (such as fcClient and fcSelfService) fall into this category, as do Windows services (such as SEC.NET and RuleManager). The few seconds saved (if that) at application startup time just don’t matter.
So where does it matter? It might matter in short-lived apps that need to start up quickly, do their work, and then terminate. For example, a business rule that calls a script or executable. i.e. a script that changes the severity of a case if its been stagnant for too long. These little apps need to start up, do some work, then end. And we want them to do their work quickly, especially if we need to run these scripts hundreds (or thousands) of times per day. So saving a few seconds in each of those instances might matter. (We’ll hold off on the discussion that there might be a better architectural solution to this type of problem anyway.)
Flipping the cache file switch
In your application’s config file, you can tell the fcSDK to not use cache files. The data will still be cached in memory, but not read from or written to cache files.
To disable cache files, simply set fchoice.nocachefile = true in your application config file (app.config for .NET apps, fc.env for COM-based apps).
This will force the fcSDK to read the data from the database every time the app starts up.
More details on Using Cached Data and fcSDK configuration can be found in the fcSDK documentation.
Hopefully this post will give you a little insight into the benefits and pitfalls of fcSDK caching, and perhaps even give you some things to think about next time you catch yourself in premature optimization mode.
