Coherence 3.5: POF Extractor/Updater
This article is part 3 of a 3 part series on my favorite new features in Coherence 3.5.
Ever since Coherence added support for .NET (and more recently C++, which can be implied when discussing .NET below) clients, we’ve always been asked this question:
When do I have to provide both .NET and Java implementations of my classes?
With each new release of Coherence, it becomes less of a requirement to provide .NET and Java implementations of cache objects. Here is a timeline of the evolution of multi language support:
Coherence 3.2/3.3
Support for .NET clients. .NET objects are serialized into a platform neutral serialization format (POF) and sent over TCP to a proxy server. The proxy server deserializes these objects and serializes them into Java format before sending into the grid for storage, thus the requirement for .NET and Java versions of each type.
Coherence 3.4
Support for .NET and C++ clients. Grid is enhanced to allow for POF binaries to be stored natively in the grid, thus removing the deserialization/serialization step previously required in the proxy servers. .NET and Java versions of cached objects are required for:
- Entry processors
- Queries
- Cache Store
- Key association
For applications with .NET clients that only do puts and gets, there is no need for Java versions of their objects in the grid.
Coherence 3.5
New in 3.5 is the ability for cache servers to extract and update data in POF binaries without deserializing the binary into an object. This is done via PofExtractors and PofUpdaters. A PofExtractor is an implementation of ValueExtractor, which is an interface that defines how to extract data from objects. The most common extractor in use today is ReflectionExtractor, which simply means that the provided method will be invoked on the target object, and the result from that method is returned.
This means that operations that rely on extractors (such as queries and some entry processors) can now be executed on the server side without needing Java classes to represent the data types.
Here is an example. Let’s say you have the following type (I wrote it in Java, but this could also be done in .NET)
public class Person implements PortableObject { public Person() { } public Person(String sFirstName, String sLastName, String sEmail) { m_sFirstName = sFirstName; m_sLastName = sLastName; m_sEmail = sEmail; } // getters and setters omitted.. public void readExternal(PofReader in) throws IOException { m_sFirstName = in.readString(FIRST_NAME); m_sLastName = in.readString(LAST_NAME); m_sEmail = in.readString(EMAIL); } public void writeExternal(PofWriter out) throws IOException { out.writeString(FIRST_NAME, m_sFirstName); out.writeString(LAST_NAME, m_sLastName); out.writeString(EMAIL, m_sEmail); } private String m_sFirstName; private String m_sLastName; private String m_sEmail; public static final int FIRST_NAME = 0; public static final int LAST_NAME = 1; public static final int EMAIL = 2; } |
Now for some sample code on executing a query:
NamedCache pofCache = CacheFactory.getCache("pof"); // These names are fictitious: any resemblence to real people // is coincidental! pofCache.put(1, new Person("Bob", "Smith", "bob.smith@google.com")); pofCache.put(2, new Person("Jane", "Doe", "jane.doe@yahoo.com")); pofCache.put(3, new Person("Fred", "James", "fred.james@oracle.com")); pofCache.put(4, new Person("Amy", "Jones", "amy.jones@oracle.com")); pofCache.put(5, new Person("Ted", "Black", "ted.black@google.com")); // Query for oracle.com addresses Set keys = pofCache.keySet(new LikeFilter(new PofExtractor(Person.EMAIL), "%@oracle.com", '\\', false)); assert keys.size() == 2; assert keys.contains(3); assert keys.contains(4); |
The cache configuration (note the system-property override in the serializer config; this comes into play later):
<?xml version="1.0"?> <!DOCTYPE cache-config SYSTEM "cache-config.dtd"> <cache-config> <caching-scheme-mapping> <cache-mapping> <cache-name>pof</cache-name> <scheme-name>pof</scheme-name> </cache-mapping> </caching-scheme-mapping> <caching-schemes> <distributed-scheme> <scheme-name>pof</scheme-name> <serializer> <class-name>com.tangosol.io.pof.ConfigurablePofContext</class-name> <init-params> <init-param> <param-type>string</param-type> <param-value system-property="pof.config">pof-config.xml</param-value> </init-param> </init-params> </serializer> <service-name>PofDistributedService</service-name> <backing-map-scheme> <local-scheme /> </backing-map-scheme> <autostart>true</autostart> </distributed-scheme> </caching-schemes> </cache-config> |
And, the POF configuration on the client:
<!DOCTYPE pof-config SYSTEM "pof-config.dtd"> <pof-config> <user-type-list> <include>coherence-pof-config.xml</include> <user-type> <type-id>10001</type-id> <class-name>com.tangosol.examples.pof.Person</class-name> </user-type> </user-type-list> </pof-config> |
To run this, I set up a cache server without adding any extra classes to the classpath. I only provided the above cache configuration, and I supplied the following to the command line:
-Dpof.config=coherence-pof-config.xml |
Why did I do this? This is because the server side does not need to know about the client’s POF configuration since it does not need to deserialize the objects. Therefore I’m simply supplying the default cache configuration that ships with Coherence.
Given the addition of this new feature, we can modify the list from 3.4 as such:
Entry processorsQueries- Cache Store
- Key association
To summarize, the introduction of POF extractors and updaters means that .NET clients only need Java implementations of their respective classes when performing CacheStore operations and/or key association.
