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)
