| Hi Fred,
That's odd... I've been reading the EOF docs (yeah, I'm a crazy man) and I came across this nugget just yesterday:
"EOEditingContexts use weak references to the EOEnterpriseObjects registered with them. EOEnterpriseObjects hold a strong reference to the EOEditingContext in which they are registered. These types of references prevent an EOEditingContext from being garbage collected while an EOEnterpriseObject still requires it."
From what that says, The EOs should have strong references to the EC so it shouldn't get garbage collected (Not that I'm a GC expert, so this might be perfectly normal)
What EC are the EOs in? Is it an EC just for this purpose, or is it one that is used by other code as well? Maybe some other code is disposing the EC?
The EOF documentation () gives this tip to create strong references from the EC to the EO, but I don't think that's going to change things, but I don't think it could hurt either in this situation:
"You can force an EOEditingContext to hold strong references to all of its EOEnterpriseObjects by invoking either setInstancesRetainRegisteredObjects or setRetainsRegisteredObjects on an editing context in which no enterprise objects are registered."
Dave On Jun 1, 2011, at 8:11 AM, Frédéric JECKER wrote: Hi list,
My app uses a singleton object to manage communication with third party app. In order to save some database queries, this singleton statically "caches" some simple EO's within an NSArray.
This works pretty well except that sometimes I encounter such messages : java.lang.IllegalStateException: Attempt to send message to an object after its editing context was disposed
Digging the stacktrace made me think that the cached EO's EOEditingContext has been eaten by the garbage collector. Is there a way to avoid this ?
Regards
Fred
|