When choosing suitable cache implementation to be clustered with Terracotta I’ve run into separate Terracotta Integration Module named DistributedMap wich provides basic caching abilities such as support for different eviction policies etc. This cache implementation seems to be easy configurable, but when it comes to production-ready clustering I’ve found that I need to find answers to some questions:
1. Have anyboby used this TIM before, is there anybody who’ve tried to use this TIM? Any fallacies?
2. DistributedMap gets easily configured, but how about next scenario: what if we start 2 Terracotta clients and each will have its DistributedMap configured differently. Will Terracotta server update existing configuration, provided by client1 or leave simply it unchanged.
When choosing suitable cache implementation to be clustered with Terracotta I’ve run into separate
Share
I just talked to a customer today using DistributedMap in production.
As for the configuration – I believe the configuration is contained within the instance. Since a DistributedMap does not contain any roots where shared state would overlap with another instance, each instance would be separate from one another (meaning you can make as many independent DistributedMaps as you like).
Note that a DistributedMap isn’t really clustered until you make it clustered by adding it to a shared graph. This can be done by adding it to an already clustered POJO (of your own creation, or for example a HashMap already clustered) or by marking it as a root (a common approach and the one suggested by the docs).