geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Stolz <>
Subject Re: Global PDX Types -> Move to Region Level?
Date Wed, 05 Apr 2017 16:42:19 GMT
There's nothing to prevent putting the same object into multiple regions.
The type catalog for a database shouldn't be relative to a table.
It should be database wide.

The real problem in this case is the proliferation of PDX Types caused by
using JSON documents that have only some of their fields populated, and
have their fields in arbitrary orders. The documents in the particular case
studied really are intended to all be the same type, but it's difficult to
tell because they are structurally mutated in so many ways.

It might be possible to make Geode figure out that they are all the same
type, but the real best-practice here is make sure you structure your JSON
documents consistently so that Geode can know that they are all of the same
type. Don't leave fields empty, default them to null or zero. Don't change
the order of the fields.

This behavioral change will make the JSON documents as structured as the
Java Objects representing the same data would be. Geode doesn't have
PDXtype explosion with Java Objects.

Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771

On Wed, Apr 5, 2017 at 5:51 AM, Olivier Mallassi <
> wrote:

> I do not know about the negative impact but could  you elaborate about the
> DLock?
> thx.
> On Fri, Mar 31, 2017 at 7:48 PM, Real Wes <> wrote:
> >
> > Would there be a negative impact in moving PDXType’s to the region level
> > instead of the cache level?  On the positive side, when there is an
> object
> > with a variable number of fields being stored in a partitioned region, we
> > would get rid of the distributed lock.  As it is now at the cache level,
> a
> > DLock is made, slowing performance.  Another positive is that export
> would
> > go much, much, much faster in systems with a lot of PDXType’s because all
> > PDXType’s are exported with every region.
> >
> > Thanks,
> > Wes
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message