@Region annotation when using Spring Data Gemfire

Question

I am developing a data service using Spring Data and Gemfire. There is an annotation

@Region("<region name>")

to specify which Gemfire region the POJO is going to be stored in.

It requires the name of the configured Gemfire region. I feel like hard-coding the name of the region is a bad practice, since the Gemfire cluster is going to be managed by a separate team and I believe the region name should be totally configurable.

Is there any better practice to avoid hard coding the region name?

Answer 1

The region name must be shared by all processes that access the region. This is analogous to a table name in a relational database. In this sense, it is no different than JPA or Hibernate annotations that declare the table name in which the POJO will be stored. IIRC, using Spring Data Repositories, if @Region is not present it will get it from the class name. But either way, the corresponding region must exist. If your application is a client to the GemFire grid, you must also configure a client region with the same name as the corresponding region on the server. If it's a peer than you must create the region (either a partition or a replica). These things may be done with Spring configuration or native GemFire configuration, but in any event, the shared region name must be known in advance and if it changes, it must change everywhere.

Answer 2

Could you use Spring Expression Language to inject the name of the Region?

We inject a value from a config bean, which itself is based on an XML file, into a @Value annotation eg:

@Value("#{config.dataSourceConfig.dbMainUsername}")

Where "config" is the name of the config bean.

Not sure is this works with all annotations tho...

Answer 3

In general, I do not think it is necessarily bad practice to specify the Region's name/path in the @Region annotation on the application domain object; it is certainly a lot more explicit.

However, I can understand the need to make such things configurable, perhaps as you promote from 1 env (eg DEV) to another (eg PROD). As such, see the recent change...

SGF-261 - allowing an application domain object/entity to be persisted to multiple Regions in a GemFire Cache

As well as this proposed, future change...

SGF-262 .