Jens, PDX is turned on in both client and server. I intentionally do not use read-serialized to keep PDX concerns out of the domain.
Since PDX is turned on throughout the cluster with the auto serializer, I would expect serialization to occur automatically, even without read-serialized=true, since there are no changes in instance variables whether new adds, deletes or name changes. I never had this trouble with using plain objects. However, introducing inheritance and interfaces seems to create a new wrinkle. I’ll test using read-serialized = true but even if that works it seems that there’s a decision tradeoff in using interfaces vs the added effort of dealing with PDXInstance in code. Thanks, Wes Williams > On Apr 1, 2016, at 7:19 PM, Jens Deppe <[email protected]> wrote: > > Wes, > > In order to be able to update domain classes you will have to use PDX and > read-serialized=true. Is that the case here? > > With non-PDX setups, ensuring the serialized state of a domain object is not > deterministic. Basically there is no way to always ensure that an object is > in a particular state. As soon as an object is in a deserialized state, it is > obviously associated with a class and thus with a specific classloader. If a > new class is deployed that particular object will not automatically be > rebuilt with the new class and classloader. That is why you're getting the > cast exceptions. > > In order to have more control you will have to use PDX. That way an object > will be serialized every time getObject() is called on the PdxInstance. This > would allow for updated domain classes to be used when the object is > referenced/retrieved in this way. > > HTH. > > --Jens > > > On Fri, Apr 1, 2016 at 12:59 PM, Real Wes Williams <[email protected] > <mailto:[email protected]>> wrote: > > What is an optimal configuration for a cluster to avoid shutting down the > grid every time domain objects change? > > Given a domain object DailyPrice with an interface Price in domain.jar and a > function reading the domain object using its interface: > > This works but requires the cluster to be shut down: > Scenario 1: domain.jar on system CLASSPATH, cluster shut down, domain.jar > copied into locator/cluster_config/cluster, cluster restart > Results: Geode deploys the domain.jar and everything works fine. > Cost: Need to shut down rather than simply undeploy/ deploy. > > Scenario 2: domain.jar on system CLASSPATH, cluster stays up, AND domain.jar > undeploy/ deploy > Results: com.company.domain.DailyPrice cannot be cast to > com.company.domain.Price > > Scenario 3: domain.jar on gfsh start server —classpath=domain.jar AND > domain.jar undeploy/ deploy > Results: com.company.domain.DailyPrice cannot be cast to > com.company.domain.Price > > Scenario 4: No classpath AND domain.jar undeploy/ deploy > Results: com.company.domain.DailyPrice cannot be cast to > com.company.domain.Price > > Scenario 5: no classpath, cluster shut down, domain.jar copied into > locator/cluster_config/cluster, cluster restart > Results: com.company.domain.DailyPrice cannot be cast to > com.company.domain.Price > > Is there a way to avoid the class path conflict and avoid bouncing the > cluster? > > Thanks, > Wes >
