For each specified data item that belongs to the cast-out class, the system returns the name of the data item, user-defined data, if any, from the directory entry for the data item, and the number of cache structure elements allocated to the data entry.

When it is time to cast out changed data that is associated with a specific cast-out class, use the READ_COCLASS request to determine which data items belong to the cast-out class. For each entry that the READ_COCLASS returns, you can then issue the CASTOUT_DATA request, write the entry to permanent storage, and build a list of names for each of the data items in the cast-out class that you can use as input to the UNLOCK_CASTOUT request. When you have completed building the list of names for the data items, you can issue a single UNLOCK_CASTOUT request to release the cast-out locks for the data items.

If your protocol relies on external serialization, you need to hold a lock to serialize access to any data items. For serialization recommendations and sample scenarios that show how to establish serialization, see Serializing and Managing Access to Shared Data.

Timing and READ_COCLASS Requests

When you issue the READ_COCLASS request, consider the impact of timing issues on serialization. If another user creates a new data item in the cache after you have issued a READ_COCLASS request with criteria that matches the data item but before the request completes, the request might not contain information for the new data item. If you want to ensure that when your request completes, cast-out class information for all data items matching your criteria has been included, you must hold serialization throughout the request processing. Serialization needs to remain in effect for both the initial request, and any subsequent request restarts that might be required as a result of a timeout, and the scope of the serialization must prevent any other user from creating a new entry that matches the criteria on the READ_COCLASS request.