If you use an NSUndoManager, it is recommended that you call this after performing very large saveChanges that involved large amounts of data.
In our experience, the NSUndoManager should be considered an integral part of an EOEditingContext and neither be crippled nor removed. Calling
is safe and can be done in your project's descendent of EOEditingContext after a successful call to
In WO 5.3 and above, setting the NSUndoManager to null will create the following error if you try to delete and save an EO that has a delete rule of "deny" on an existing relationship:
java.lang.RuntimeException: java.lang.IllegalStateException: Editing context needs an undo manager to recover from delete propagation problems. Do not set the undo manager of this editing context to null.
Additionally, if you simply remove undo registration, you'll find that little undo / redo pieces are still allocated in memory... which defeats the purpose of removing registration. This can be verified with a tool such as Jprofiler, etc. Any tool which allows you to view the java heap and memory allocations.
If what you are really after is processing many EOs in a long running process you should consider making an array of primary keys and materializing them onesy-twosy in a temporary EOEditingContext. Before exiting the loop call
ec = null
Another way to say it, make an EOEditingContext for each pass through the loop then clear it out before the next pass.
This is a description of the current behavior in 5.3 that one might be able to gather if one were to, say, decompile and review the entire process - not that i would ever do this or condone it, of course - but if you DID, you would probably gather exactly this info, which is pretty well documented (and seems to behave to-spec) in the 5.2 release notes: