When my daughter was born one of the first things we had to deal with was to come up with her name. As we had not discussed it earlier, the arguments ensued and for a long time me and my wife did not have a complete agreement. Now besides her official name we call her by ten other names and 8 out of these 10 does not even have a literary meaning. But we love to call her by those names as they express hers and ours different moods. Naming your cache is one such process.
Common Cache Conventions
- All upper case
- All lower case
- Upper or lower case with delimiters
- Application Name dot cache name
- Camel case
- Cryptic internal looking name
- No exposed names
Though by Java conventions all upper case words are considered constants you would need to be cautious with cache names. Cache configurations are considered to be "updatable" at deployment time. As the updates are manual, cache names should also be humane. All upper case though are okay if short but long words or a combination of words all upper case does have a screaming feel and should be avoided.
All lower case
Though much easier on eyes all lower case cache names suffer from the problem of illegibility if the name is either long or a combination of words. Use of "-" or "_" can also be considered as long as this convention is followed throughout the configuration.
Some coherence grids are configured to provide cache services for more that one application. Usually the cache access to this type of infrastructure are also backed up by a policy file that could define access permissions like application(A) can read but not write into a cache belonging to application (B) etc. These kinds of caches are better configured with names qualified by the application name. The application name should be short max 4 letters and could be all upper case. Like, a cache "Positions" of a Finance application can be named FIN.Positions while an audit cache "Statistics" could be AUD.Statistics and the Java policy (if any exists) can use regular expressions based on application names to set the Permissions.
This is likely the most human readable format. As it also follows the Java class naming convention there exist an uniformity in how the classes and the caches are named.
A new convention has been introduced since Coherence transaction schemes after version 3.6. Some caches that are supposed to be used internally i.e, not meant for business usage can be defined with cryptic names. For example the Transaction scheme uses cache names starting with prefix "V$TXN-". If you desire to follow this convention then it would be good to create an internal cache configuration and use the DefaultConfigurableCacheFactory to initialize the caches through its ensureCache APIs. It will also be the responsibility of the application developer to tune these named caches - typically. Do not expose such a cache configuration for deployment time tuning.
Some application may not want to expose the names at all. This may fall under two categories:
- Coherence bundles a default cache configuration that can be used to create caches with names starting with dist- or repl- etc. Following this convention makes the configuration very short and clean. But it also risks a loose usage pattern where caches either can be wrongly created or not known at all unless the code flow initializes it. A typical use of this pattern is when we do not know the cache names up front. Like if an application provides employee Id to email address mapping for companies. As companies use this service the application can create dist-CustomerA or dist-CustomerB as they join this service. No infrastructure changes would be needed and it is easier to expand the application.
- Cache mappings does not need to exist in the configuration and the application can use the name of the cache service to create its own caches. Though this either should be discouraged or be used in some advanced use cases. Either way, the naming convention should be consistent across all the components of the application.