Thanks guys. I have actually once case where right now I cant avoid using circular REF. Does using DataSerializable interfaces solve this issue... I really want to avoid using JVM serialization as it seems to take a lot more space
On Sat, Jul 1, 2017 at 4:04 AM, Darrel Schneider <[email protected]> wrote: > You can mix the different serialization frameworks even in a single object > graph. For example your top level value object could use PdxSerializable > and then it could have a field that uses DataSerializable and it could have > a field that uses Serializable. The only restriction is that once an object > in the graph uses standard java serialization (i.e. Serializable or > Externalizable) then every object under that object in the graph will also > only use standard java serialization. > Another thing to know is that some jdk classes get special treatment by > geode serialization. For example if you create an ArrayList and serialize > it then we do not use its standard java serialization but instead have > geode code that knows how to serialize an ArrayList in a special way that > is more efficient for geode. But if you create a subclass of ArrayList then > it is just serialized with the normal rules for domain classes. Note that > if the ArrayList is reached from a parent object that used standard java > serialization then this special code that serializes ArrayLists is not used. > If you look at all the static methods on DataSerializer (the read* and > write* ones) you will see all the jdk classes that have special built in > serialization code. > A really bad anti-pattern is to have one of these special container > classes contain references to objects that will use standard java > serialization. It will work but the size of your serialized data will be > much larger than expected. In this case you are much better off introducing > an object above the container that uses java serialization so that the > whole graph under it will all use java serialization. For some of the jdk > collections you could do this by simply creating a subclass of the jdk > container class and use it in place the standard jdk class. > > > > On Fri, Jun 30, 2017 at 9:49 AM, John Blum <[email protected]> wrote: > >> Hi Amit- >> >> Regarding... >> >> *> Can we combine the two serialization Java and PDX? * >> >> I was tempted to say NO until I thought well, what would happen if some >> of my application domain objects implemented java.io.Serializable while >> others implemented org.apache.geode.pdx.PdxSerializable or >> org.apache.geode.DataSerializable. >> >> I am not sure actually; I have never tried this. I would not recommend >> it... i.e. I would stick to 1 serialization strategy. You could have >> adverse affects if read-serialized was set to true, or you were running >> OQL queries on a Region that stored a mix of serialized objects (e.g. PDX + >> Java Serialized), etc. >> >> Remember (as I stated earlier)... >> >> "*If either DataSerialization or PDX Serialization is configured, even >> if your application domain object implements java.io >> <http://java.io>.Serializable, then Geode will prefer its own serialization >> mechanics over Java Serialization**.*" >> >> >> Finally, as for... >> >> *> By the way somehow in my case PDX is used although I never supplied >> any PDX ReflectionBasedAutoSerializer. Can you let me know the possible >> reasons for it?* >> >> The only way PDX will be used is if you... >> >> >> 1. Set the pdx-serializer-ref attribute on the <gfe:cache> element in >> the SDG XML namespace to any PdxSerializer implementation, for example... >> >> <bean *id=**"mySerializer"* class="org.example.app.geode.s >> erialization.MyPdxSerializer"/> >> >> <gfe:cache properties-ref="gemfireProperties" *pdx-serializer-ref=* >> *"mySerializer"* pdx-read-serialized="true" >> pdx-persistent="true" pdx-disk-store="pdxStore"/> >> >> Or, if you set the pdxSerializer property >> <http://docs.spring.io/spring-data-gemfire/docs/current/api/org/springframework/data/gemfire/CacheFactoryBean.html#setPdxSerializer-java.lang.Object-> >> [1] >> on the [Client]CacheFactoryBean. It also does NOT matter if >> ReflectionBasedAutoSerializer is used or not. In fact, I would not >> recommend using ReflectionBasedAutoSerializer. I would rather use SDG's >> MappingPdxSerializer or custom, dedicated PdxSerializers. >> >> >> 2. Or, your application domain object implements >> org.apache.geode.pdx.PdxSerializable. >> >> >> if either of these 2 things are true, then PDX is used. >> >> Regards, >> John >> >> >> [1] http://docs.spring.io/spring-data-gemfire/docs/current/ >> api/org/springframework/data/gemfire/CacheFactoryBean.html# >> setPdxSerializer-java.lang.Object- >> >> >> On Thu, Jun 29, 2017 at 10:50 PM, Amit Pandey <[email protected]> >> wrote: >> >>> Hey John, >>> >>> Can we combine the two serialization Java and PDX? I want to use Java >>> for some domain objects which have circular dependencies until we figure >>> out a better way to represent them and use PDX for others? >>> >>> By the way somehow in my case PDX is used although I never supplied any >>> PDX ReflectionBasedAutoSerializer. >>> >>> Can you let me know the possible reasons for it? >>> >>> Regards >>> >>> On Fri, Jun 30, 2017 at 8:23 AM, John Blum <[email protected]> wrote: >>> >>>> Right! There is no special configuration required to use *Java >>>> Serialization* with Apache Geode, regardless if SDG is in play or >>>> not. Your application domain object just needs to implement >>>> java.io.Serializable. >>>> >>>> However, if you decide to use Geode's *DataSerialization* framework >>>> <http://geode.apache.org/docs/guide/11/developing/data_serialization/gemfire_data_serialization.html> >>>> [1] >>>> or even PDX >>>> <http://geode.apache.org/docs/guide/11/developing/data_serialization/gemfire_pdx_serialization.html> >>>> [2] >>>> (and you should consider this), then SDG supports this too. For instance, >>>> here is an example config >>>> <https://github.com/spring-projects/spring-data-geode/blob/master/src/test/resources/org/springframework/data/gemfire/config/xml/cache-using-pdx-ns.xml#L18-L21> >>>> [3] >>>> of using SDG to configure PDX. Here is a slightly more involved >>>> example >>>> <https://github.com/spring-projects/spring-data-geode/blob/master/src/test/java/org/springframework/data/gemfire/function/ClientCacheFunctionExecutionWithPdxIntegrationTest.java> >>>> [6] >>>> that uses *Spring* JavaConfig and "custom", "composed" *PdxSerializers* >>>> for the application domain object types (i.e. Person & Address). >>>> >>>> And, if you combine Geode's PDX Serialization framework [2] with *Spring >>>> Data's* "Mapping" infrastructure >>>> <http://docs.spring.io/spring-data-gemfire/docs/current/reference/html/#mapping.pdx-serializer> >>>> [4], >>>> there is a special PdxSerializer in SDG called MappingPdxSerializer >>>> <http://docs.spring.io/spring-data-gemfire/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html> >>>> [5] that uses the SD "*Mapping meta-data*" to serialize your >>>> application domain object types to PDX. >>>> >>>> Of *Java Serialization*, DataSerialization and PDX, it is recommended >>>> that you use and prefer PDX as it offers the most flexibility and is more >>>> efficient than *Java Serialization* (though it does not handle cycles; >>>> so be careful there). Of the 3, *DataSerialization* is the most >>>> efficient. >>>> >>>> If either DataSerialization or PDX Serialization is configured, even if >>>> your application domain object implements java.io.Serializable, then >>>> Geode will prefer its own serialization mechanics over *Java >>>> Serialization*. >>>> >>>> Refer to Geode's documentation >>>> <http://geode.apache.org/docs/guide/11/developing/data_serialization/data_serialization_options.html> >>>> [7] >>>> on serialization for more details. >>>> >>>> Hope this helps. >>>> >>>> Regards, >>>> John >>>> >>>> >>>> [1] http://geode.apache.org/docs/guide/11/developing/data_se >>>> rialization/gemfire_data_serialization.html >>>> [2] http://geode.apache.org/docs/guide/11/developing/data_se >>>> rialization/gemfire_pdx_serialization.html >>>> [3] https://github.com/spring-projects/spring-data-geode/blo >>>> b/master/src/test/resources/org/springframework/data/gemfire >>>> /config/xml/cache-using-pdx-ns.xml#L18-L21 >>>> [4] http://docs.spring.io/spring-data-gemfire/docs/current/r >>>> eference/html/#mapping.pdx-serializer >>>> [5] http://docs.spring.io/spring-data-gemfire/docs/current/a >>>> pi/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html >>>> [6] https://github.com/spring-projects/spring-data-geode/blo >>>> b/master/src/test/java/org/springframework/data/gemfire/func >>>> tion/ClientCacheFunctionExecutionWithPdxIntegrationTest.java >>>> [7] http://geode.apache.org/docs/guide/11/developing/data_se >>>> rialization/data_serialization_options.html >>>> >>>> >>>> On Thu, Jun 29, 2017 at 4:20 PM, Kirk Lund <[email protected]> wrote: >>>> >>>>> Make the classes for your domain objects implement >>>>> java.io.Serializable and avoid specifying DataSerializable or >>>>> DataSerializers or PDX. This will result in use of Java serialization when >>>>> serializing your domain objects. It'll be slower though. >>>>> >>>>> On Thu, Jun 29, 2017 at 3:42 PM, Amit Pandey < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Guys, >>>>>> >>>>>> Whats the config for using Java Serialization in Spring Data Geode ? >>>>>> >>>>>> regards >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> -John >>>> john.blum10101 (skype) >>>> >>> >>> >> >> >> -- >> -John >> john.blum10101 (skype) >> > >
