<namedCache...> <compatibility enabled="true"/> </namedCache>
Infinispan offers the possibility to store and retrieve data in a local, embedded way, and also remotely thanks to the multiple endpoints offered, but until now if you choose one way to access the data, you were stuck with it. For example, you could not store data using the embedded interface and retrieve it via REST.
Starting with Infinispan 5.3, it is now possible to configure Infinispan caches to work in a special, compatibility mode for those users interested in accessing Infinispan in multiple ways. Achieving such compatibility requires extra work from Infinispan in order to make sure that contents are converted back and forth between the different formats of each endpoint and this is the reason why compatibility mode is disabled by default.
For compatibility mode to work as expected, all endpoints need to be configured with the same cache manager, and need to talk to the same cache. If you're using the brand new Infinispan Server distribution, this is all done for you. If you're in the mood to experiment with this in a standalone unit test, this class shows you how you can start multiple endpoints from a single class.
So, to get started using Infinispan's compatibility mode, it needs to be enabled, either via XML:
<namedCache...> <compatibility enabled="true"/> </namedCache>
Or programmatically:
ConfigurationBuilder builder = ... builder.compatibility().enable();
The key thing to remember about Infinispan's compatibility mode is that where possible, it tries to store data unmarshalling or deserializing it. It does so because the most common use case is for it to store Java objects and having Java objects stored in deserialized form means that they're very easy to use from an embedded cache. With this in mind, it makes some assumptions. For example, if something it's stored via Hot Rod, it's most likely coming from the reference Hot Rod client, which is written in Java, and which uses a marshaller that keeps binary payloads very compact. So, when the Hot Rod operation reaches the compatibility layer, it will try to unmarshall it, by default using the same default marshaller used by the Java Hot Rod client, hence providing good out-of-the-box support for the majority of cases.
It could happen though the client might be using a Hot Rod client written for another language other than Java, say Ruby or Python. In this case, some some kind of custom marshaller needs to be configured that either translates that serialized payload into a Java object to be stored in the cache, or keeps it in serialized form. Both options are valid, but of course it will have an impact on what kind of objects are retrieved from Infinispan if using the embedded cache. The marshaller is expected to implement this interface. Configuring the compatibility marshaller is optional and can be done via XML:
<namedCache...> <compatibility enabled="true" marshallerClass="com.acme.CustomMarshaller"/> </namedCache>
Or programmatically:
ConfigurationBuilder builder = ... builder.compatibility().enable().marshaller(new com.acme.CustomMarshaller());
One concrete example of this marshaller logic can be found in the SpyMemcachedCompatibleMarshaller. Spy Memcached uses their own transcoders in order to marshall objects, so the compatibility marshaller created is in charge of marshalling/unmarshalling data stored via Spy Memcached client. If you want to retrieve data stored via Spy Memcached via say Hot Rod, you can configure the Java Hot Rod client to use this same marshaller, and this is precisely what the test where the Spy Memcached marshaller is located is demonstrating.
The best code examples available showing compatibility in action can be found in the Infinispan Compatibility Mode testsuite, but more will be developed in the near future.