Memory Management and the StarTeam SDK

over 7 years ago

The SDK is a framework, not an application.

Memory allocated inside the SDK belongs to the owning application. It is the application responsibility to release that memory when done. Failure to do so will result in running out of memory (32 bit runtimes) or continuous page swapping (64 bit runtimes). In either case, the results aren't pleasant.

When an application connects and logs on to a StarTeam server using the SDK Server object, and the connect/logOn api's, the SDK creates an internal cache, which is shared across all in-memory server object instances connected to the same physical StarTeam server (hostname, port) endpoint. 

As applications work with projects and their views, the cache fills up with data, which stays in memory until the cache is destroyed, (all server instances referencing the cache are disconnected) or earlier, if the data itself is discarded by well behaved applications.

The view is the most granular container of cache data. As an example, if a view is queried for folders, files and change requests, and each of these types are then queried for all the property values of each of their instances, all the data associated with each instance of each type is mapped to the owning view in the cache.

Applications that iterate through several views, possibly across several projects, end up aggregating all the data associated with each view in memory, unless they explicitly request the cache to discard the data. The way to do this, is to close the view, using the api view.close()

The documentation for view.close() is copied below...

* Frees all cached resources associated with this view, and closes the
* associated view session.
* <p>
* Many view-related resources, such as the folder tree, item lists and so
* on, can be discarded separately. Others, however, are freed only by an
* explicit call to close().
* <p>
* After a view is closed, the view object is still useful. The view session
* is automatically re-opened when needed, and data is re-fetched from the
* server on demand.
public void View::close() {...}

Two SDK classes that are also of interest are ViewPollingAgent and ViewConfigurationDiffer.

These classes internally allocate a View, based on a specific rolled back configuration.

Applications that use either of these two classes are responsible for calling the close() method, which in turn ensures that internally allocated views are closed.

Well behaved applications will choose to call close() explicitly when done with a view (or view polling agent or view configuration differ) and not wait for a finalizer to kick in. View.close() should not be programmed into class finalizers(), neither in java nor in c#, since the implementation issues a network call to the StarTeam server, requesting the server to discard the cached view session.

A combination of proper memory management in conjunction with optimized network (client-server) traffic will result in well behaved, scalable, SDK applications.


How To-Best Practice
Comment List
Related Discussions