Pivotal Knowledge Base

Follow

How to avoid PDX conflicts when accessing different clusters from same client

Applies To

GemFire

Purpose

Describe details about PDX and how to avoid PDX conflicts when accessing several clusters from one client.

Description

Clients are already designed to simultaneously handle multiple versions of class's PDXType. You will of course need to follow the rules to retain forwards/backwards compatibility to avoid conflicts. The client doesn't juggle multiple sets of metadata for each PDX Type. Rather, it creates its own based on startup/runtime reflection on the local version of the class, populates concrete instances of the class from any PDXInstance it receives, and generates PDXInstance instances for transmission to servers based on the the local definition as well. The client does retain/retransmit any unknown field/value pairs received from a server, even though they are basically invisible to the client.

The metadata is shared throughout the client cache.

If you configure pools pointing to two different clusters there is a chance that it can cause PDX conflict or mismatches. How to avoid that?

The important thing in this scenario is to make sure the different clusters have different values for distributed-system-id. As long as you do that the two different clusters won't assign the same PDX type id to the different classes - because the distributed-system-id becomes part of the PDX type id.

Comments

Powered by Zendesk