Re: java.lang.outofmemory
Re: java.lang.outofmemory
- Subject: Re: java.lang.outofmemory
- From: Ken Anderson <email@hidden>
- Date: Tue, 07 Mar 2006 19:08:26 -0500
Paul,
I used to think that too - anyone from the old days do :) Art proved
me wrong though...
Ken
On Mar 7, 2006, at 6:39 PM, Paul Lynch wrote:
On 7 Mar 2006, at 23:11, Art Isbell wrote:
On Mar 7, 2006, at 1:00 PM, Paul Lynch wrote:
saveChanges() doesn't release snapshots, unfortunately, which I
would surmise is the problem.
But if snapshot reference counting is working as advertised,
dereferencing the only editing context containing references to
the snapshots should release them.
Snapshots are stored at a lower level than editing context, so they
won't be released. I forget where they are stored, but it's
possibly the parent object store. If you're using the default
object store strategy, then all sessions will be sharing the same
parent, and snapshots may be retained. The undo manager can also
hold on to snapshots for you.
it may also be acceptable to use dispose(),
dispose() should be invoked when an editing context is about to
be garbage-collected, so sending an explicit dispose() message
seems redundant.
I mentioned it because it is explicitly stated in the Apple memory
management documentation, "EOEditingContext Concepts":
"Frequent use of invalidateAllObjects or
invalidateObjectsWithGlobalIDs can have significant performance
impact. If you no longer need the EOs in the editing context, it
may be faster to simply do:
ec.dispose();"
but invalidateAllObjects(), and its variants, are the only way
to flush the snapshots.
Other than removing any references which doesn't involve the
invalidateAllObjects() overhead of converting all of the objects
to faults. So invoking invalidateAllObjects() seems like a waste
to me.
invalidateAllObjects is worth avoiding, I agree. I have seen a
suggestion to setUndoManager(null), assuming of course that you
aren't using WO's undo/redo methods.
Paul
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40anderhome.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden