The second one is to use the Java Services API. This is the preferred
mean. You will need to create a jar file, accessible through the same
class loader as Mondrian, and add a file called
/META-INF/services/mondrian.spi.SegmentCache which contains
the name of the segment cache implementation to use.

The third method is to use the SegmentCache.SegmentCacheInjector.
This is to be used as a last resort, in environments where the
cache implementation is not part of the same class loader as Mondrian.
In those cases, Mondrian can't dynamically load the segment cache class.
The injector serves as an IoC-like service.

All of the segment caches that Mondrian discovers, throughout all
of these means of discovery, will be used simultaneously. It is not possible
to register new segment caches for a previously existing instance
of a Mondrian server. The caches are scanned and configured when each
Mondrian instance gets created.

Implementations are expected to be thread-safe. Mondrian is likely to
submit multiple requests at the same time, from different threads. It is the
responsibility of the cache implementation to maintain a consistent
state.

Implementations must implement a time-out policy, if needed. Mondrian
knows that a call to the cache might take a while. (Mondrian uses worker
threads to call into the cache for precisely that reason.) Left to its
own devices, Mondrian will wait forever for a call to complete. The cache
implementation might know that a call to get(mondrian.spi.SegmentHeader) that has taken 100
milliseconds already is probably hung, so it should return null or throw
an exception. Then Mondrian can get on with its life, and get the segment
some other way.

Implementations must provide a default empty constructor.
Mondrian creates one segment cache instance per Mondrian server.
There could be more than one Mondrian server running in the same JVM.