[jira] [Created] (GEODE-2256) Create Colocation Example

["Joey McAllister (JIRA)" <ji...@apache.org>]

Joey McAllister created GEODE-2256:
--------------------------------------

             Summary: Create Colocation Example
                 Key: GEODE-2256
                 URL: https://issues.apache.org/jira/browse/GEODE-2256
             Project: Geode
          Issue Type: New Feature
          Components: docs
            Reporter: Joey McAllister


Mike Stolz recommended on the Geode User list that "We should make a generic implementation of what Udo described here as part of the Geode examples. It's such a frequently used pattern."

Here is the original request from Amit Pandey:
{quote}
I saw that in order to co locate different caches  you can use "colocated-with" attribute.

However how does Spring or Geode determine (based on which attributes ) that they will be collocated.  Lets say two regions containing Customer and Account needs to be collocated. I want to use the accountPK present in both classes for collocation and not on other attributes which might have the same name (to give an artificial example lets say there is a "status" attribute which is Y in both but which I dont want to be used for determining collocation.  
{quote}

And here is Udo's response:

{quote}
Colocation works by making sure that the same buckets are placed on the
same server. It works in a parent-child relationship. Where RegionB is
colocated with RegionA.

For colocation to work you either need to use the same key or a
PartitionResolver. A PartitionResolver is a custom impl that provides
the mechanism, that determines what bucket each entry is put into, a way
to make sure that entries for RegionB get the same bucket as the
colocated entry in RegionA.

Be very careful that the PartitionResolver uses the key only and not the
value.

In your case I'm sure that an Account would have reference to its
parent, the customer. So I would use the customerKey for the colocation.
Remember that keys can be "complex". i.e Have an accountID and a
customerID. If you make the complex object have it's hashCode and equals
point at the accountID then it will behave the same way as you would if
you only used the accountID. Then, with the customerID being present in
the complex accountID, you could then have a partitionResolver on the
the Accounts region that would return the customerID (which would then
be the same key that you used for the customer in your Customer region).
Which means any account that is entered will be colocated with its
customer information.

In short, if you make sure that the mechanism that determines the bucket
number always returns the same bucket number for colocated objects,
related data will be stored on the same server.

http://geode.apache.org/docs/guide/developing/partitioned_regions/using_custom_partition_resolvers.html
{quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)