Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EclipseLink/DesignDocs/232063"
(→Document History) |
|||
Line 20: | Line 20: | ||
| [[User:Gordon.yorke.oracle.com|Gordon Yorke]] | | [[User:Gordon.yorke.oracle.com|Gordon Yorke]] | ||
| Update after initial feedback | | Update after initial feedback | ||
+ | |- | ||
+ | | 2010/10/18 | ||
+ | | [[User:Gordon.yorke.oracle.com|Gordon Yorke]] | ||
+ | | IN PROGRESS: Update after additional feedback from Doug Clarke | ||
|} | |} | ||
Line 27: | Line 31: | ||
* Relationships between JPA 2.0 Cachable(false) and Cachable(true) Entities should be supported | * Relationships between JPA 2.0 Cachable(false) and Cachable(true) Entities should be supported | ||
+ | * Allow for relationships to be configurable as non-cacheable and provide corresponding behaviour | ||
+ | * Support returning query results for cached data that are isolated from the shared cache. | ||
== Concepts == | == Concepts == | ||
− | Currently EclipseLink uses the Isolated Cache functionality to provide @Cacheable(False) requirements. The Isolated Cache functionality was created with security as a primary requirement and Isolated Entities were not allowed to reference Shared Cache Entities. Transitioning Isolated Caches to the JPA 2.0 @Cacheable() requirements means this functionality must adapt and be more flexible as @Cacheable(true) Entities must be able to reference @Cacheable(false) Entities. | + | Currently EclipseLink supports a shared Entity cache by default and uses the Isolated Cache functionality to provide @Cacheable(False) requirements. The Isolated Cache functionality was created with security as a primary requirement and Isolated Entities were not allowed to reference Shared Cache Entities. Transitioning Isolated Caches to the JPA 2.0 @Cacheable() requirements means this functionality must adapt and be more flexible as @Cacheable(true) Entities must be able to reference @Cacheable(false) Entities. |
+ | The solution to this is two fold. First we must be able to create copies of the shared cache instances to allow for mixing cachable data with non cachable relationships. Second we must allow for non-cacheable relationships where the relationships are populated in an isolation from the shared cache. | ||
== Requirements == | == Requirements == | ||
* Transparent support for relationships from @Cacheable(true) to @Cacheable(false). | * Transparent support for relationships from @Cacheable(true) to @Cacheable(false). | ||
+ | * Change @Cache() to have boolean 'cacheable' attribute and additional | ||
* Separate Isolated configuration from @Cacheable(false) | * Separate Isolated configuration from @Cacheable(false) | ||
** Create multi-valued configuration option | ** Create multi-valued configuration option |
Revision as of 16:38, 18 October 2010
Design Specification:
Relationships between non-Cachable and Cachable Entities
Document History
Date | Author | Version Description & Notes |
---|---|---|
2010/05/27 | Gordon Yorke | Initial creation of this doccumentation |
2010/06/23 | Gordon Yorke | Update after initial feedback |
2010/10/18 | Gordon Yorke | IN PROGRESS: Update after additional feedback from Doug Clarke |
Project overview
Goals:
- Relationships between JPA 2.0 Cachable(false) and Cachable(true) Entities should be supported
- Allow for relationships to be configurable as non-cacheable and provide corresponding behaviour
- Support returning query results for cached data that are isolated from the shared cache.
Concepts
Currently EclipseLink supports a shared Entity cache by default and uses the Isolated Cache functionality to provide @Cacheable(False) requirements. The Isolated Cache functionality was created with security as a primary requirement and Isolated Entities were not allowed to reference Shared Cache Entities. Transitioning Isolated Caches to the JPA 2.0 @Cacheable() requirements means this functionality must adapt and be more flexible as @Cacheable(true) Entities must be able to reference @Cacheable(false) Entities. The solution to this is two fold. First we must be able to create copies of the shared cache instances to allow for mixing cachable data with non cachable relationships. Second we must allow for non-cacheable relationships where the relationships are populated in an isolation from the shared cache.
Requirements
- Transparent support for relationships from @Cacheable(true) to @Cacheable(false).
- Change @Cache() to have boolean 'cacheable' attribute and additional
- Separate Isolated configuration from @Cacheable(false)
- Create multi-valued configuration option
- SHARED - Entities are fully cached within the IdentityMaps (normal behaviour)
- PROTECTED - Users aways receive cloned versions of these classes but data is cached in shared cache
- ISOLATED - Data is not cached in shared cache ( @Cacheable(false) ) has same isolated behaviour as today
- When the metadata is processed any SHARED Entities that reference PROTECTED or ISOLATED Entities will be elevated to PROTECTED.
- Create multi-valued configuration option
EclipseLink JPA Metadata
- @Cache(isolaton=IsolationType.PROTECTED)
- <cache isolation="PROTECTED"/>
High Level Design
- PROTECTED/ISOLATED Entities will always be cloned when returned
- ISOLATED Entities will not be cached but will be reloaded each time
- ForeignReferenceMappings will track when they reference ISOLATED Entities
- This allows the mapping to determine how and when the relationship should be built.
- Relationships owned by the PROTECTED/SHARED Entity will cache Within the PROTECTED/SHARED Entity in the form of PK(s) values.
- Un-Owned relationships will not be built or cached
Design / Functionality
Design Notes
Testing
API
Config files
Documentation
Open Issues
This section lists the open issues that are still pending that must be decided prior to fully implementing this project's requirements.
Issue # | Owner | Description / Notes |
---|---|---|
Decisions
This section lists decisions made. These are intended to document the resolution of open issues or constraints added to the project that are important.
Issue # | Description / Notes | Decision |
---|---|---|
Future Considerations
During the research for this project the following items were identified as out of scope but are captured here as potential future enhancements. If agreed upon during the review process these should be logged in the bug system.