Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

EclipseLink/Development/WeakIndirection

Weak Indirection

This page is intended to facilitate discussion of bug 278650 and provide and alternative work-arounds for the described issue.

Problem

In addition to the large number of objects, our persistence framework has a lot of interlinking (many 1-M and 1-1 back reference mappings throughout the application). The object graph that is loaded into memory is extremely intertwined. In instances of our application where data-sets are very large we are running into the situation where the GC cannot free memory because active threads retain hard references to objects, which, because of QueryValueHolder, retains hard references to related objects throughout our object model. This is true regardless of the setting in the IdentityMap.

Research/Discussion

The following types of indirection and their associated states need to be considered:

No Indirection Policy: org.eclipse.persistence.internal.indirection.NoIndirectionPolicy

Basic Indirection

  • Policies:
    • org.eclipse.persistence.internal.indirection.BasicIndirectionPolicy
    • org.eclipse.persistence.internal.indirection.ContainerIndirectionPolicy
    • org.eclipse.persistence.internal.indirection.WeavedObjectBasicIndirectionPolicy
  • ValueHolderInterface (implementors)
    • ValueHolder: Default type used in new instances
    • DatabaseValueHolder
      • QueryBasedValueHolder
        • BatchValueHolder
      • UnitOfWorkValueHolder
        • UnitOfWorkQueryValueHolder

Note: Excluded Transformer, Remote, and Cache implementations for now

Transparent Indirection Policy:

  • IndirectContainer (Transparent indirection for collections)
    • IndirectList
    • IndirectSet
    • IndirectMap

Proxy Indirection Policy: org.eclipse.persistence.internal.indirection.ProxyIndirectionPolicy

Solutions/Work-arounds

S1. Break Relationships

While not ideal from a model usability perspective this solution should be listed for completeness. In some domain models the elimination of relationships is helpful to address potential usage issue in the application. The most common example of this is removal of large collection mappings where the entire collection is not needed for any operations and the inclusion of the mapping (typically 1:M) incurs a large cost to simply add an element to the collection. It is better in these cases to have a set of queries that allows the collection values to be accessed in part.

S2. Custom IndirectionPolicy

This is still under investigation but the idea is to provide your own indirection policy where weka references can be used instead of hard references.

Back to the top