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 "Talk:EclipseLink/DesignDocs/232063"
(→PROTECTED vs Relationship Isolation) |
(→Feedback) |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | == PROTECTED vs Relationship Caching == | |
| − | + | ||
| − | == PROTECTED vs Relationship | + | |
--[[User:Douglas.clarke.oracle.com|Doug]] 17:22, 4 October 2010 (UTC) | --[[User:Douglas.clarke.oracle.com|Doug]] 17:22, 4 October 2010 (UTC) | ||
| + | |||
I have been working on a multi-tenant and temporal version of the employee demo and have realized that I believe the issue we need to address is how relationships are populated and cached. Currently when an entity is stored in the shared cache its relationships are populated there. I believe we should allow the configuration of relationships where they are only populated within the EntityManager (UnitOfWork) and not in the shared cache. This would apply on the read and write (merge) so that when inspecting the shared cache you would only ever see an uninstantiated relationship. | I have been working on a multi-tenant and temporal version of the employee demo and have realized that I believe the issue we need to address is how relationships are populated and cached. Currently when an entity is stored in the shared cache its relationships are populated there. I believe we should allow the configuration of relationships where they are only populated within the EntityManager (UnitOfWork) and not in the shared cache. This would apply on the read and write (merge) so that when inspecting the shared cache you would only ever see an uninstantiated relationship. | ||
| − | * When an entity | + | === Scenarios === |
| + | |||
| + | * When an entity with @Cacheable(true) has a relationship to an entity with @Cacheable(false) we would default to and only allow the relationship to @Cacheable(false) | ||
* When an entity has a relationship to another entity (shared or isolated caching) and there is @AdditionalCriteria configured on the target we would default to only populating the relationship when read into the UnitOfWork | * When an entity has a relationship to another entity (shared or isolated caching) and there is @AdditionalCriteria configured on the target we would default to only populating the relationship when read into the UnitOfWork | ||
* Users could force this to avoid populating relationships in the shared cache that may cause cache life-cycle dependencies. This could allow an entity with a FULL cache to have a relationship to an entity with a WEAK cache but since it is not populated in the shared cache the WEAK garbage collection would only be governed by application references to the target. | * Users could force this to avoid populating relationships in the shared cache that may cause cache life-cycle dependencies. This could allow an entity with a FULL cache to have a relationship to an entity with a WEAK cache but since it is not populated in the shared cache the WEAK garbage collection would only be governed by application references to the target. | ||
* Users wishing to more dynamically customize the queries for relationships could avoid corrupting the shared cache and only have their limited query result populated in the UnitOfWork | * Users wishing to more dynamically customize the queries for relationships could avoid corrupting the shared cache and only have their limited query result populated in the UnitOfWork | ||
| + | |||
| + | === Cacheable Relationships Examples === | ||
| + | |||
| + | <source lang="java"> | ||
| + | public class Department { | ||
| + | ... | ||
| + | @OneToMany(mappedBy="department") | ||
| + | @Cacheable(false) | ||
| + | List<Employee> employees; | ||
| + | </source> | ||
Latest revision as of 15:00, 4 October 2010
PROTECTED vs Relationship Caching
--Doug 17:22, 4 October 2010 (UTC)
I have been working on a multi-tenant and temporal version of the employee demo and have realized that I believe the issue we need to address is how relationships are populated and cached. Currently when an entity is stored in the shared cache its relationships are populated there. I believe we should allow the configuration of relationships where they are only populated within the EntityManager (UnitOfWork) and not in the shared cache. This would apply on the read and write (merge) so that when inspecting the shared cache you would only ever see an uninstantiated relationship.
Scenarios
- When an entity with @Cacheable(true) has a relationship to an entity with @Cacheable(false) we would default to and only allow the relationship to @Cacheable(false)
- When an entity has a relationship to another entity (shared or isolated caching) and there is @AdditionalCriteria configured on the target we would default to only populating the relationship when read into the UnitOfWork
- Users could force this to avoid populating relationships in the shared cache that may cause cache life-cycle dependencies. This could allow an entity with a FULL cache to have a relationship to an entity with a WEAK cache but since it is not populated in the shared cache the WEAK garbage collection would only be governed by application references to the target.
- Users wishing to more dynamically customize the queries for relationships could avoid corrupting the shared cache and only have their limited query result populated in the UnitOfWork
Cacheable Relationships Examples
public class Department { ... @OneToMany(mappedBy="department") @Cacheable(false) List<Employee> employees;