Re: java.lang.outofmemory
Re: java.lang.outofmemory
- Subject: Re: java.lang.outofmemory
- From: Chuck Hill <email@hidden>
- Date: Tue, 7 Mar 2006 17:18:18 -0800
On Mar 7, 2006, at 4:49 PM, Denis Stanton wrote:
On 8/03/2006, at 12:54 PM, Art Isbell wrote:
Your statement seems to contradict
On 8/03/2006, at 1:08 PM, Ken Anderson wrote:
I used to think that too ... Art proved me wrong though...
Hi guys
This has been an interesting discussion as it touches on area that
has caused me some grief - outOfMemory problems are hard to solve,
partly because they tend to fail to record all the usual evidence.
Have you reached an agreement? Each new email seems to invalidate
the previous advice (a bit like the old "how does WebObjects
licensing work" discussion :-) )
LOL!
It would really nice if one of you experts could say what
combination of saveChanges(), dispose(), invalidateAllObjects(),
system.gc() etc is most likely to avoid memory blowout when
handling large data volumes, and then if the other experts could
voice agreement ? I keep bookmarking what seems like definitive
advice only to have it contradicted by a following message.
Can I just muddy the waters a bit? Unless you have disabled snapshot
reference counting, if there are no references from an _EO_ to a
snapshot, the snapshot will in time (rather quickly in my experience)
be discarded and garbage collected. EO references come from your
code. EO references can also come indirectly from an EC. I don't
believe that an EC maintains counted references to snapshots, but I
could be mistaken in this belief. EC strong references to an EO
should come from unsaved changes (updates and deletes). At some
point in the past, it seemed to be that the EC was at times retaining
strong references to the EO when it should not have. This may have
been due to the undo manager or something else internal to the EC.
I'm not sure if this was a bug, a misunderstanding on my part, or me
misusing the editing context. In any event, the result of this was
that snapshots were not being released when I thought they should
be. Disposing of the editing context fixed / appeared to fix this
problem.
In terms of limiting memory usage, I make it a practice to call
ec.undoManager().removeAllActions() after a successful save or after
a call to revert(). I find this easier to manage than setting the
undo manager to null and remembering that I need it to process
deletions. I make it a practice to call dispose() on an EC if I know
that it will not be used again. I have not measured how much
practical benefit this has over allowing the finalizer to call dispose
(), but it is an easy practice to follow and causes no harm in any
event.
As for invalidating objects, this is something to be avoided. I
admit that I have been driven to desperation a couple of times and
used this, but only with regrets and reservations.
Chuck
--
Coming in 2006 - an introduction to web applications using WebObjects
and Xcode http://www.global-village.net/wointro
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/practical_webobjects
_______________________________________________
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