SDO Considerations

After you decide that the system may benefit from having a table loaded in memory, you must decide whether the table should be included in SDO cache. The following guidelines can be followed in this analysis:

  • An SDO cache table can be read-only during an application server session. This means that only pure read-only tables are good candidates for SDO as the updating of SDO tables is more involved, requiring that the application server be recycled twice.

  • When SDO is enabled via SODCACHE and a table is marked with “Allow Update” set to true, the application conducts further verification through Redis to check for any updates occurring after the data has been cached. If an update to the table is detected, the system invalidates the cache, retrieves the updated data from the database, and reloads the cache accordingly. Tables that change very frequently in a day may be a poor candidate for SDO cache; however, tables that change infrequently per day are now potential SDO cache candidates with this new caching mechanism.

  • Only data object getObjectByKey() calls can take advantage of the SDO caching mechanism.

  • Query objects cannot be set up to be SDO cached.

  • Tables with a large number of rows may benefit by following the SDO cache mechanism along with expiration logic as a limited number of rows can be stored in memory forcing database calls for the less frequently referred rows. Incorporating expiration logic is not normally recommended.

  • Only a finite number of tables can be marked to be memory resident or be stored on the SDO cache because of memory limitations. Careful estimation of the memory requirements is required before marking a table for SDO. Factors to consider are the number of rows and record size and typical growth in record access rates for SDO.

  • The CACHE_DELAY_DURATION property has been added to the Application Parameter (APPCTRL) page to optimize SDO cache validation and improve performance for SDO-cached tables that are updateable. The default value of CACHE_DELAY_DURATION is set to 300 seconds. This property sets a delay period during which the application will read data directly from the cache without validating whether there have been recent updates to the data requiring a cache refresh. After the delay period has passed, the application will check if the cache is stale, and if necessary, it will fetch updated data from the database. Higher values for this property improve the SDO cache performance but increase the potential likelihood that the data has changed and the cache is stale.