How can you trace a Siebel cache refresh? (Doc ID 1602250.1)

Last updated on NOVEMBER 24, 2022

Applies to:

Purpose

This document explains how cache refreshes in the Siebel application can be traced. There are several caches within a Siebel object manager process that provide access to frequently used data like responsibilities, runtime events, personalization rules,  LOV and many more.

As this data can be dynamic, caches can be refreshed with user sessions still connected and no need to bounce a component or a specific component process.

The cache request itself is triggered by an administrative user and then forwarded by the SRBroker component. SRBroker is contacting each object manager process in an enterprise and is requesting this process to refresh its cache and read new data from the database.

In order to do this, SRbroker needs a short period of time where the cache in a given process is not used by any active user session.

If there is at least one active session using the current state of the cache, the SRBroker has to wait.

It is apparent that  in a heavily used system this might cause delays until a cache actually is refreshed for every single process.

Under some unexpected situation, it can happen that SRBroker has to wait very long time until a cache refresh can be performed and it appears to hang. That can happen for example when a session holding the cache is going into some sort of endless loop and not releasing the cache in a reasonable amount of time. For details about SRBroker hangs and how to investigate, see note 1517299.1 - How to troubleshoot Siebel SRBroker hangs.

Scope

 This note is intended to help to understand when and how a cache refresh was triggered, which process has already refreshed its cache and which have the refresh still pending.

Details

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.