Because the PI-SDK objects model corresponding elements in PI Servers, they must access the servers to obtain their state. To avoid repeated access to the server for duplicate requests, the PI-SDK stores state information it has retrieved from the server within the objects. In cases where future client requests can be reasonably anticipated, or the performance cost is low, the PI-SDK may retrieve extra or unsolicited information. For example if a single PointAttribute for a PIPoint is requested, in some instances the PI-SDK will retrieve a number of the point's attributes in anticipation of future requests. This storage, or caching, improves the performance of client requests through the PI-SDK.
One drawback of caching data is that the data ages. The longer the data is held, the more likely it is that someone has changed the source of the data, perhaps invalidating the cached representation. There are two approaches to solving this problem, user-driven refreshes, and subscribing for updates from the server. The first approach is available in the current implementation; the second will be delivered in future releases.
The IRefresh interface is provided to allow programs to control refreshing the cached information for an object and its descendants in the object hierarchy. It has a single method; Refresh. This method, as implemented by each object, ensures that by the next data access, the object will retrieve information from the associated server and updates the object's state. As the model is a hierarchy, calling Refresh on a high level object will force refreshes on the descendants of the object. The IRefresh interface is a secondary (non-default) interface for these objects. C and C++ programs can call QueryInterface to retrieve this interface. Visual Basic users employ a slightly different approach as described above in "Calling Secondary Interfaces from Visual Basic."
A "global" Refresh method is also provided with the PISDK object at the top of the hierarchy. This method takes an object as an argument and effectively queries the passed object for its IRefresh interface and if successful calls the Refresh method on the interface.
Calling Refresh, as it downloads data from the server, is an expensive call, especially if called on an object high up in the hierarchy. This facility should be used in moderation as it can impact a program's performance and put undue load on servers.
Future versions of the PI-SDK will contract with the server to receive notifications of significant changes. This will likely be done "behind the scenes," keeping the cache current transparently. It will likely not be possible to obtain notifications for all changes on all types of objects from all supported server types. For example, a PI2 Server will not send notifications when the digital state table has been edited. For this class of object, the Refresh method will still be the easiest way to ensure the currency of the cached object state.