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

["Alberto Bustamante Reyes (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GEODE-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alberto Bustamante Reyes updated GEODE-2256:
--------------------------------------------
    Labels: pull-request-available  (was: )

> 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
>            Assignee: Alberto Bustamante Reyes
>            Priority: Minor
>              Labels: pull-request-available
>          Time Spent: 40m
>  Remaining Estimate: 0h
>
> 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
(v8.3.2#803003)