Re: java.lang.outofmemory
Re: java.lang.outofmemory
- Subject: Re: java.lang.outofmemory
- From: Art Isbell <email@hidden>
- Date: Tue, 7 Mar 2006 15:09:17 -1000
On Mar 7, 2006, at 2:49 PM, Denis Stanton wrote:
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.
Possibly one of the reasons this type of problem is difficult to
solve is the non-deterministic manner in which Java garbage
collects. In the old days (yes, I was there as well :-) when an
Objective-C EO was freed, by damn, it was freed :-) None of this
waiting around for the JVM to do its cleaning. So you could probably
do all the right things programmatically and get nailed because
you're fetching more objects before Java has finished cleaning up the
old ones. It's probably best to increase the maximum Java heap size
as long as doing so doesn't cause paging. Too bad the JVM has to
have a maximum Java heap size.
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'm no expert in Java memory management. Whenever Java throws an
out of memory exception, I've just doubled the maximum heap size
which has solved the problem. But I'm not fetching huge data sets.
I just have a bias against using invalidateAllObjects() because, for
me, it's caused more problems than it's solved. dispose() is invoked
automatically, so I don't see a reason to invoke it explicitly. I've
read that forcing garbage collection isn't a great idea, so I've
never done so. I just use a temporary editing context (don't forget
to lock it!) when I'm concerned about memory usage and need to use
EO's, and dereference the editing context as soon as I've finished
assuming that EOF will take care of freeing snapshots automatically.
When I've written utilities that transfer data from one DB to
another, I've worked at the EOAdaptor level avoiding EO creation, the
overhead of EOControl, etc. Doing so is certainly faster and uses
less memory, but isn't convenient if one needs to do some EO processing.
Aloha,
Art
_______________________________________________
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