We are trying to make two Gemfire Repositories, Since there are two different bean objects, to which they are dealing with, but we want to store these two bean objects into same gemfire region.
Is this a right way to do it? If "Yes" then How to do it?
Thanks in advance.
...we want to store these two bean objects into same gemfire region. Is this a right way to do it?
That is debatable. However, it really depends on your application requirements and use cases. It also depends on the relationship between the objects.
For instance, if you have a Customer which extends (is-a) Person then storing both Customers and People in the same Region may not seem all that bad.
But, if you are storing Customers and say Purchases, where a Customer is composed of, or "has-a" Set/List of Purchases, then that is harder to digest. It also makes querying this Region much more tricky since the (OQL) Query engine does inspect object type information for properties/fields, even method invocations if invoked inside the query, which could lead to ClassCastExceptions and NoSuch[Method|Field]Exceptions. So, be careful.
I tend to be more of a purist in this regard and would suggest/recommend that you keep the application domain model objects in separate Regions, especially in the "has-a" relationship case. It is possible to store the data in separate Regions and still "collocate" the data (i.e. the Regions), particularly for querying purposes. See here for more details.
But...
All of this is not to say you cannot achieve storing objects of similar, or even different types, in the same Region.
Typically, you annotate your business, application domain objects with the @Region annotation to specify which GemFire cache Region the object will be stored in, like so...
@Region("Customers")
class Customer extends Person { ... }
@Region("Purchases")
class Purchase { ... }
Then you go on to define your Repositories...
interface CustomerRepository extends GemfireRepository<Customer, Long> { .. }
interface PurchaseRepository extends GemfireRepository<Purchase, Long> { .. }
Normally, when SD Commons Repository infrastructure and SD GemFire's Repository extension detects the Repository interfaces, it inspects the type parameters, sees the application domain objects (i.e. Customer & Purchase), inspects those and determine the Regions to which each application domain object belongs by...
Either detecting and inspecting the @Region annotation attribute value, or..
Using the "simple" name of the domain object class name as the Region name (i.e. "Customer" Region of the Customer domain object).
That determines the Region.
However, if you want both Customer and Purchase objects to be stored in the SAME Region, then SD GemFire extends the common Repository infrastructure and allows you to annotate your Repository interfaces with the @Region annotation, like so...
@Region("Customers")
interface CustomerRepository extends GemfireRepository<Customer, Long> { .. }
@Region("Customers")
interface PurchaseRepository extends GemfireRepository<Purchase, Long> { .. }
In this case, both Customer and Purchase objects will be stored in the "Customers" Region since the @Region annotation on the Repository interfaces overrides the @Region annotation on the individual application domain objects.
There were valid reasons and use cases to allow this feature specifically in Spring Data GemFire. To find out more information on this, read here.
In whatever approach you take, you should carefully weigh your options.
Hope this helps!
Cheers, John
