+1 to what Udo stated; additionally.. It is also advisable, if you required more fine grained control over the serialization of your POJOs (i.e. necessarily more than the ReflectionBasedAutoSerializer <http://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/ReflectionBasedAutoSerializer.html> [2]), that you use, say, the *Composite* Design Pattern <https://en.wikipedia.org/wiki/Composite_pattern> [1] to "compose" a collection of PdxSerializer implementations that are specific to each type of POJO. This is even preferable over having each POJO implement Geode's PdxSerializable interface which affords you similar fine grained control.
It is unfortunate that you cannot register more than 1 PdxSerializer per cache instance for different domain object, but essentially, you can achieve a similar effect using the Composite Design Pattern. Here is 1 example... https://github.com/spring-projects/spring-data-gemfire/blob/master/src/test/java/org/springframework/data/gemfire/function/ClientCacheFunctionExecutionWithPdxIntegrationTest.java#L312-L348 This "*ComposablePdxSerializer*" is composed of 2 PdxSerializer implementations, 1 for each domain object... // PersonPdxSerializer https://github.com/spring-projects/spring-data-gemfire/blob/master/src/test/java/org/springframework/data/gemfire/function/ClientCacheFunctionExecutionWithPdxIntegrationTest.java#L408-L430 // AddressPdxSerializer https://github.com/spring-projects/spring-data-gemfire/blob/master/src/test/java/org/springframework/data/gemfire/function/ClientCacheFunctionExecutionWithPdxIntegrationTest.java#L382-L407 And then the "*ComposablePdxSerializer*" (and individual, POJO based PdxSerializer implementations) are configured and registered accordingly... https://github.com/spring-projects/spring-data-gemfire/blob/master/src/test/resources/org/springframework/data/gemfire/function/ClientCacheFunctionExecutionWithPdxIntegrationTest-server-context.xml#L28-L42 Of course, this will all shown in *Spring Data Geode* (XML) configuration, but a similar configuration can be achieved using the equivalent Geode config where *Spring* (*Data Geode*) is not used. -j [1] https://en.wikipedia.org/wiki/Composite_pattern [2] http://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/ReflectionBasedAutoSerializer.html On Tue, Mar 28, 2017 at 11:20 AM, Udo Kohlmeyer <ukohlme...@pivotal.io> wrote: > Hi there Olivier. > > It is hard to say what you are trying to do... but to answer your > question... The typical approach is to start a clientcache which spans > lifetime of the client application. It is not something that I would want > to start/stop as the mood strikes. > > As for generic PdxSerializer vs Pojo specific serializer, I would error on > the side of Pojo specific serializer, as the serialization logic is defined > on the pojo. BUT if you don't want to "taint" your pojo with serialization > code, you could use a generic PDXSerializer. In this case you can write > your own or use the provided ReflectionBasedAutoSerializer. [0] > > So to *hopefully* answer your question. 1 clientcache, with either 1 > generic PdxSerializer (custom or ReflectionAutoSerializer) or 2 pojo > specific PdxSerializable implementations. > > --Udo > > [0] - https://geode.apache.org/docs/guide/developing/data_serializ > ation/gemfire_pdx_serialization.html > > > > > On 3/28/17 10:47, Olivier NOUGUIER wrote: > >> Hi, >> In a reactive extension to connect Apache Geode with akka-stream in >> alpakka community project [0], I don't know how to use ClientCache in an >> efficient way. >> >> Given: >> >> - 2 Pojos: Animal and Person >> - 2 Regions for each >> >> Should I use 2 ClientCaches with 2 custom PDXSerializer or only one >> ClientCache with a more generic PDXSerializer ? >> >> Another way to ask, if ClientCache is expensive to instanciate. >> >> Thanks in advance. >> >> PS: I've hesitate to post this on the user list... >> >> >> [0]: https://github.com/cheleb/alpakka/tree/geode/geode >> >> > -- -John john.blum10101 (skype)
