[
https://issues.apache.org/jira/browse/GEODE-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joey McAllister updated GEODE-2256:
-----------------------------------
Priority: Minor (was: Major)
> 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
> Priority: Minor
>
> 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)
