Content Engine Java and .NET APIs

Upgrading multi-column database indexes

In previous releases, a database administrator could manually create a multi-column index using the native database tools. The 5.2.1 release includes a new class, CmIndexDefinition, that provides support for creating multi-column indexes programmatically (or via Administration Console for Content Platform Engine).

If your system contains manually created multi-column indexes that you want to incorporate into the Content Platform Engine metadata, you can upgrade these indexes by creating a new CmIndexDefinition object for each index. The name specified for the CmIndexDefinition object must be the same as the name for the manually created index. The server will detect that the physical index already exists and, in such cases, will update only the metadata in the tables (skipping the actual index creation but performing the index definition creation).

Upgrading Clients with Cross-Release Support

The Content Engine Java API now supports cross-release class loading capability, allowing a single instance of a Java application to connect to multiple Content Platform Engine (CPE) server releases simultaneously. You can upgrade your existing Java applications to connect to a 5.2.1 version of CPE server as well as to older versions of the server. For more information, see Developing a Cross-Release Application.

Retaining random IDs

In releases prior to 5.2.1, the unique identifiers assigned to objects were generated using an algorithm that produces completely random values. In the 5.2.1 release, a new algorithm is available that produces sequential IDs. Sequential IDs have a time- and counter-based portion that is combined with a random portion in such a way that consecutively created IDs are sequential (monotonic) per the natural ordering applied by the underlying database.

The new UseSequentialIds property on the ObjectStore interface specifies whether an object store should assign random or sequential IDs when a new object is created in that object store. An indexed database column or a table with a clustered index on the primary key containing sequential IDs might be stored more compactly and managed more efficiently than completely random IDs, hence potentially providing a performance benefit and space savings.

The default value for this property is true (assign sequential IDs). If you do not want new objects in an object store to have sequential IDs, set the value of the UseSequentialIds property to false.

MemberOfGroups Property No Longer Cached

The MemberOfGroups property is no longer cached in PrincipalCache on the Content Platform Engine server. This property might contain thousands of group objects. Because the server cannot control the maximum limit of groups, caching this property can lead to an out-of-memory condition on the server.

As a result of this change, it might take longer for a client application to retrieve the MemberOfGroups property for a User or Group object from the server. You might see degraded performance if the application calls one or more of the following Content Platform Engine API methods:

User user = Factory.User.fetchInstance(...);
GroupSet parentGroups = user.get_MemberOfGroups();

OR

Group group = Factory.Group.fetchInstance(...);
GroupSet parentGroups = group.get_MemberOfGroups();

OR

GroupSet parentGroups;
SecurityPrincipal principal = Factory.SecurityPrincipal.fetchInstance(...);
if (principal instanceof User)
parentGroups = ((User)principal).get_MemberOfGroups();
else
parentGroups = ((Group)principal).get_MemberOfGroups();

If you experience degraded performance with this release, you can resolve or mitigate the issue with the following actions:

• Unless your business logic requires the list of groups that a user belongs to, the MemberOfGroups property should not be retrieved. If the property is required, reduce redundant calls to the related API methods from the client. If possible, call the method once, and reuse the property.
• Increase the size of PrincipalCache on the Content Platform Engine server. Every time the server builds this property, it first tries to retrieve each individual group from PrincipalCache. So if the group is found from the cache, it will save a round trip to the directory server and hence improve performance. This approach will work better when users have many overlapping parent groups. If your directory has more than the default of 8192 unique groups, then increasing the maximum size limit of PrincipalCache might result in performance improvements.

  For more information about this cache, see Security Caching.