Apache Geode CHANGELOG

Creating Custom Attributes for Regions and Entries

Use custom attributes to store information related to your region or its entries in your cache. These attributes are only visible to the local application and are not distributed.

You can define custom user attributes so you can associate data with the region or entry and retrieve it later. Unlike the other configuration settings, these attributes are used only by your application.

Note: User attributes are not distributed.

  1. Create a Java Object with your attribute definitions.

  2. Attach the object to the region or to an entry:

    • Region.setUserAttribute(userAttributeObject)
    • Region.getEntry(key).setUserAttribute(userAttributeObject)

  3. Get the attribute value:

    • Region.getUserAttribute()
    • Region.getEntry(key).getUserAttribute()

This example stores attributes for later retrieval by a cache writer.

// Attach a user attribute to a Region with database info for table portfolio
Object myAttribute = "portfolio"; 
final Region portfolios = 
      new RegionFactory().setCacheWriter(new PortfolioDBWriter()).create("Portfolios"); 
Portfolios.setUserAttribute(myAttribute);

//Implement a cache writer that reads the user attribute setting
public class PortfolioDBWriter extends CacheWriterAdapter {
  public void beforeCreate(RegionEvent event) {
    table = (String)event.getRegion().getUserAttribute();
    // update database table using name from attribute
        . . .
  }
}

Limitations and Alternatives

User attributes are not distributed to other processes, so if you need to define each attribute in every process that uses the region or entry. You need to update every instance of the region separately. User attributes are not stored to disk for region persistence or overflow, so they cannot be recovered to reinitialize the region.

If your application requires features not supported by user attributes, an alternative is to create a separate region to hold this data instead. For instance, a region, AttributesRegion, defined by you, could use region names as keys and the user attributes as values. Changes to AttributesRegion would be distributed to other processes, and you could configure the region for persistence or overflow if needed.