ObjectContext Memory Management has been edited by Andrus Adamchik (Nov 22, 2006).

(View changes)

Content:

As of release 2.0, all implementations of ObjectContext (specifically DataContext) retained hard references to all registered objects on a premise that the context itself would eventually go out of scope and release all those objects. This resulted in memory leaks when a context was used for processing large data sets and/or when it stayed around for a long time (e.g application-scoped context, etc.).

Release 3.0 features a leak-free DataContext that uses weak references to store registered objects. This way registered objects are allowed to be garbage collected by the VM if they are not referenced elsewhere in the application. "Elsewhere" usually means one of the following:

When to avoid using this feature

In some cases automatic cleaning of registered objects may result in extra DB trips. Depending on a situation, this may or may not be critical, so users will need to weight the choices of better performance vs. smaller memory use. Here is a few scenarios like that:

  • Nested DataContexts: When a child nested DataContext commits to parent, parent using weak references may have already deallocated some of the objects being committed and will have to refetch them.
  • ROP: When an ROP client commits to the server, parent server DataContext using weak references may have already deallocated some of the objects being committed and will have to refetch them.

To ensure that weak references are not used, create a DataContext manually, passing a regular HashMap to the ObjectStore constructor.

TODO: an example, and figure out how to make it a parameter in the Modeler

Related Jira Issues:

Reply via email to