1

GemfireRepository is a gemfire specific implementation of CrudRepository but the spring data gemfire reference guide says if we use GemfireRepository then we need to have our domain classes correctly mapped to configured regions as the bottstrap process will fail otherwise..does that mean that we need to have @Region annotation on the domain classes?In case we use CrudRepository then @Region annotation is not required because CrudRepository is not dependent on Region ?

So I am using GemfireRepository and I have a cacheloader configured as plug in to a region and the cacheloader depends on the GemfireRepository to fetch the data from RDBMS. So according to the reference documentation if GemfireRepository is internally dependent on Region..then does that create a circular dependency?

Arghya Sadhu
  • 41,002
  • 9
  • 78
  • 107

1 Answers1

0

The SDG GemfireRepository interface extends SDC's CrudRepository interface and adds a couple of methods (findAll(:Sort), and an overloaded save(:Wrapper):T method), See...

http://docs.spring.io/spring-data-gemfire/docs/current/api/org/springframework/data/gemfire/repository/GemfireRepository.html

GemfireRepository interface is "backed" by the SimpleGemfireRepository class.

Whether your application-specific Repository interface extends GemfireRepository or CrudRepository, or even just org.springframework.data.repository.Repository, does not really matter. Extending a Repository interface provided by the framework only determines what methods will be exposed in the backing implementation by the "Proxy" created with the framework.

E.g. if you wanted to create a read-only Repo, you would directly extend org.springframework.data.repository.Repository, and copy only the "read-only" methods from the CrudRepository interface into your application-specific Repository interface (e.g. findOne(:ID), findAll(), exists(:ID), i.e. no data store mutating methods, such as save(:S):S).

But, by using the namespace element in your Spring config, you are instructing the framework to use SDG's Repository infrastructure to handle persistent operations of your application domain objects into GemFire, and specifically Regions. Therefore, either the application domain object must be annotated with @Region, or now, SDG allows an application Repository interface to be annotated with @Region, in cases where you want your application domain object needs to be stored in multiple Regions of GemFire. See 8.1, Entity Mapping in the SDG Ref Guide, for further details..

http://docs.spring.io/spring-data-gemfire/docs/1.4.0.RELEASE/reference/html/mapping.html#mapping.entities

Regarding the "circular dependency"... yes, it creates a circular dependency...

Region A -> CacheLoader A -> ARepository -> Region A.

And will lead to a...

org.springframework.beans.factory.BeanCurrentlyInCreationException

You need to break the cycle.

John Blum
  • 7,381
  • 1
  • 20
  • 30
  • Yes I am getting org.springframework.beans.factory.BeanCurrentlyInCreationException exception..can you suggest how can I break the dependency except using CrudRepository in place of GemfireRepository..in this case @Region annotation is not required on the domain object and hence the circular dependency is not happening.. – Arghya Sadhu Jun 27 '14 at 09:41
  • It technically does not make sense to have Region A -> CacheLoader A -> Repository A -> Region A. That is like saying on a cache miss from Region A, use a CacheLoader to load from Region A since the CacheLoader (A) will delegate to Repository A that loads from Region A. It makes more sense that the CacheLoader for Region A is backed by an external data store (e.g. RDBMS) or even, perhaps, another Region (e.g. B), although the later is quite rare. – John Blum Jun 27 '14 at 09:44
  • Actually I am using cacheloader to load the data from oracle RDBMS...I could not clearly understand -"CacheLoader (A) will delegate to Repository A that loads from Region A"....and basically what is the purpose of @Region annotation on a domain object....my understanding is this:GemfireRepository is used to load data from a Gemfire Region and only CrudRepository(not GemfireRepository) should be used if we need to load the data from external RDBMS..Am I correct? – Arghya Sadhu Jun 27 '14 at 09:58
  • No, GemfireRepository has nothing to do with an RDBMS. GemfireRepository is specific to GemFire and is SDG's implementation of and extension to SDC's Repository abstraction, which are implemented by various Spring Data projects (e.g. Spring Data GemFire) to interface with and perform certain data access operations on the underly, integrated data store (i.e. GemFire in SDG's case, or JpaRepository in Spring Data JPA's case). So, what I mean by Repository A is enabling SDG's repository infrastructure support is for the purpose of creating Repos to GemFire Regions, whether or not they extend... – John Blum Jul 06 '14 at 18:18
  • GemfireRepository or CrudRepository directly. Again, GemfireRepository is just an extension of CrudRepository but in all cases a GemfireRepository enabled by SDG's Repository intfrastructure... @EnableGemfireRepositories, or using XML... is for the purpose of accessing a GemFire Region. So a Region A that has a CacheLoader A that uses a (SDG) Repository A (or B) does not make much sense. If you want to access a database from a CacheLoader, then you probably want Spring Data JPA's Repository implementation. – John Blum Jul 06 '14 at 18:22
  • See... http://docs.spring.io/spring-data/jpa/docs/1.6.1.RELEASE/reference/html/jpa.repositories.html for further details. – John Blum Jul 06 '14 at 18:23