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"
(New page: == Feedback ==) |
(→PROTECTED vs Relationship Isolation: new section) |
||
| Line 1: | Line 1: | ||
== Feedback == | == Feedback == | ||
| + | |||
| + | == PROTECTED vs Relationship Isolation == | ||
| + | |||
| + | 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 in the shared cache has a relationship to an entity not in the shared cache we would default to only populate this relationship when building it in 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 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 | ||
Revision as of 13:22, 4 October 2010
Feedback
PROTECTED vs Relationship Isolation
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 in the shared cache has a relationship to an entity not in the shared cache we would default to only populate this relationship when building it in 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 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