Object Caching

At the client level, the primary unit of information that we see is called an item. But “under the hood”, an item is really comprised of two parts:

• An object (or artifact) contains most of the persistent information we see in an item. The object has properties such as Name, Description, Created By, Version, and so forth.
• A view member associates a specific object with a specific view and folder. In addition to properties that identify the view, folder, and object, the view member has configuration properties such as Branch On Change and Configuration Time that affect how the object is accessed through the corresponding view.

View members are specific to a view, whereas objects can be referenced by any number of views. At the client level, view member and object properties are blended into the unified items that users see. The information associated with view members is comparatively small. In contrast, the properties of a single object revision can consist of up to 100KB of data or more. When a large number of items are fetched from the StarTeam Server, the response can be several megabytes in length. Even when a client enables compression, a large fetch request can require several seconds to a minute or more depending on network speed and latency.

When object caching is enabled, an MPX MPX Cache Agent stores most (but not all) of the properties for configured object types. An object caching-aware client can then fetch those properties from a network-near MPX Cache Agent, resulting in faster performance compared to fetching from the StarTeam Server. Object fetching is performed by the StarTeam SDK, which combines view member properties and some object properties retrieved from the StarTeam Server with object properties fetched from a MPX Cache Agent, yielding the requested items. In other words, when object caching is enabled, there is no detectable difference to client applications except for (in many cases) greater performance.

Not all properties are cached when object caching is enabled. Some properties are view-specific (e.g., Branch On Change), user-specific (e.g., Flag User List), server-calculated (e.g., Attachment Names), client-calculated (e.g., My Lock), or modifiable without creating a new revision (e.g., Comment). For different reasons, these properties are not “cacheable” and therefore are not included in persistent cache objects. When needed, these properties must be either calculated by the SDK or fetched from the StarTeam Server.

If not all object properties are cached, how effective is object caching? The vast majority of object properties, both in number and total size, are “eligible” for caching, hence object caching can be effective even though not all properties are cached. For example, for change request objects, the following properties are cached:

Addressed By, Addressed In, Addressed In View, Attachment Count, Attachment IDs, CR Number, Category, Closed On, Component, Created By, Created Time, Deleted By, Deleted Time, Description, Dot Notation, End Modified Time, Entered By, Entered On, External Reference, Fix, Last Build Tested, Modified By, Modified Time, Object ID, Parent Branch Revision, Parent ID, Parent Revision, Platform, Priority, Resolved On, Responsibility, Revision Flags, Root Object ID, Severity, Status, Synopsis, Test Command, Type, Verified On, Version, View, Work Around …plus all custom (user-defined) properties.

As with file caching, object caching uses encryption and other security measures so that cached objects can only be retrieved by authorized users. The use of object caching does not compromise StarTeam-defined security in any way.