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

Difference between revisions of "EclipseLink/DesignDocs/214661"

(New page: <div style="margin:5px;float:right;border:1px solid #000000;padding:5px">__TOC__</div> = Functional Specification: VM managed Entity detachment = [http://bugs.eclipse.org/214661 ER 214661...)
 
Line 10: Line 10:
 
! Author
 
! Author
 
! Version Description & Notes
 
! Version Description & Notes
}
+
|-}
  
 
= Project overview =
 
= Project overview =
Line 61: Line 61:
 
! Owner
 
! Owner
 
! Description / Notes
 
! Description / Notes
}
+
|-}
  
 
= Decisions =
 
= Decisions =
Line 72: Line 72:
 
! Description / Notes
 
! Description / Notes
 
! Decision
 
! Decision
}
+
|-}
  
 
= Future Considerations =
 
= Future Considerations =

Revision as of 17:17, 8 January 2008

Functional Specification: VM managed Entity detachment

ER 214661

Document History

Project overview

Allowing a Persistence Context to reference managed objects in a weak manner would provide Rich Clients an automatic memory management mechanism.

Currently JPA clients must manage memory foot print manually by controlling the lifetime of the PersistenceContext as well as the contents of the Persistence Context.

Within a Rich Client environment it is much easier for application developers to simply use the managed objects as the UI backing objects and leverage transparent persistence instead of creating a DOA layer.

Currently the only limitation with this approach is memory management. Persistence Contexts tend to grow and detaching objects is problematic. With this feature memory management can be delegated to the VMs garbage collection functionality through the use of weak references. End users must be aware of certain side effects of unpredictable detachment from the Persistence Context but as long as developers are aware of the limitations the feature should provide the needed functionality.

Goals:

Concepts

Requirements

Functionality

Design Constraints

Maintainability

GUI

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.

Date Author Version 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 # Owner Description / Notes

Future Considerations

Issue # Description / Notes Decision

Back to the top