Weird (fatal) CoreData caching behavior
Weird (fatal) CoreData caching behavior
- Subject: Weird (fatal) CoreData caching behavior
- From: "Doug Knowles" <email@hidden>
- Date: Tue, 20 Mar 2007 22:41:45 -0400
I have a CoreData app I've been working on for months, and I'm
encountering a problem that appears to be caused by CoreData caching
behavior I can't control. The user-level actions that trigger the
problem are:
- I open a document (a subclass of NSPersistentDocument), and the
application automatically performs some processing that modifies the
document/datastore;
- I close the document without saving;
- I re-open the same document, and the application crashes during the
same automatic processing.
As I look into it, it seems obvious that the NSManagedContext for the
first instance of the open document is being re-used when the file is
re-opened, and I'm suspecting that the re-used context is somehow
damaged (perhaps partially released?).
The evidence:
When I close-without-saving the document for the first time, a call to
NSLog after NSPersistentDocument.close is called indicates that the
closed document's NSManagedObjectContext (actually, a
NSKVONotifying_NSManagedObjectContext) is still in memory, with a
retainCount of 2:
2007-03-20 22:08:19.534 SLNavigator[8866] SLNDocument closed;
context(2) = <NSKVONotifying_NSManagedObjectContext: 0xd1012a0>
When I re--open the document, the automatic modification includes two
operations that use a single NSManagedObject's managedObjectContext to
find another record; what's odd is that the object's
managedObjectContext changes between the two operations, and on the
second operation, the record's managedObjectContext has the "old"
address (that of the closed document) and a className that lacks the
NSKVONotifying_ prefix.
Looking at NSLog output:
On the first operation after re-opening:
2007-03-20 22:24:44.306 SLNavigator[8866] ...using context:
<NSKVONotifying_NSManagedObjectContext: 0xd1d63a0>
On the second:
2007-03-20 22:24:45.068 SLNavigator[8866] ...using context:
<NSManagedObjectContext: 0xd1012a0>
Note the change in class name. A call to executeFetchRequest using
this context fails.
A couple of notes:
- I now construct a new NSFetchRequest for executeFetchRequest, so
this isn't a fetched property issue.
- I have used ObjectAlloc to debug this, and it confirms that the
first document's managedObjectContext remains allocated after its
"host" document has been released.
I'm stumped. Any suggestions?
As always, TIA and thanks for the great help I've received here in the past.
Regards,
Doug K;
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden