On Jun 3, 2008, at 5:52 PM, Ben Trumbull wrote:
Michael,
This error is almost always a multi-threading problem. When you
used the _debug version of Core Data, did you enable the threading
assertions with the user default -com.apple.CoreData.ThreadingDebug
3 ?
Yes, I also see this in the console:
2008-06-03 18:26:08.824 Bug5912058[5770:10b] CoreData Multithreading
assertions enabled.
What version of OSX are you using ?
I'm using 10.5.3 (9D34), installed
apple_debug_and_profile_libraries_for_mac_os_x_10.5.3_9d34.mpkg.zip
yesterday.
Is there a reason you're not using Core Data's -
mergeChangesFromContextDidSaveNotification: ?
If the object is modified (inserted, update, or deleted), you should
pass in YES to -refreshObject:mergeChanges:
Actually I am using mergeChangesFromContextDidSaveNotification:, I am
calling refreshObject:mergeChanges: with NO on the NSUpdatedObjectsKey
objects just before as this avoids the problem of Bug 5937572.
Originally I was just using the managed object context's
mergeChangesFromContextDidSaveNotification: but I noticed that the
merges weren't reflecting what had been saved in regards to some
objects relationships. For example:
1. Perform some insertions and changes on a background thread. One of
these changes is to add the inserted objects to one of the objects
relationships (which is a many-to-many reflexive relationship). Let's
say ObjectB which exists in the background thread's MOC now has 20
friends (10 of the friends are newly inserted and 10 are existing
objects).
2. The background thread's MOC saves, and is registered to receive
it's own MOC did save notification which it forwards to the main
thread using performSelectorOnMainThread:
3. The main thread's MOC has no changes and is fed the save
notification by calling mergeChangesFromContextDidSaveNotification:
and passing the notification.
At this point we can now look at ObjectA (which is the same as ObjectB
except it is owned by the main thread's MOC) which will show that it
has 10 friends. It should have 20 but the merge has deleted the 10
friends that were just inserted on the background thread, but just for
ObjectA. Looking at those 10 objects that were deleted on the main
thread you will find that they are still friends with ObjectA. This
leaves the object graph in an inconsistent state.
It seems that sometimes the call to
mergeChangesFromContextDidSaveNotification: causes an error that
shows
up in the output as "statement is still active". It appears that
object controllers that are bound to a managed object context receive
a notification
"_NSObjectsChangedInManagingContextPrivateNotification"
and they do some fetching and the error occurs when they do a fetch
request.
This implies you're modifying a MOC on a background thread that's
bound into Cocoa Bindings. Cocoa Bindings and much of AppKit expect
to effectively own their objects on the main thread. Whichever MOC
the object controllers are observing is probably being misused.
The controllers are bound to the MOC on the main thread. The
"statement is still active" exception occurs in the call to
mergeChangesFromContextDidSaveNotification: on the main thread's MOC.
I have an Xcode project that can show both bug 5937572, where the
object graph is left in an inconsistent state after a merge and bug
5982319, where the "statement is still active" exception occurs during
a merge. The project is already attached to bug 5982319 (Bug-1.zip)
and is setup to show the behavior regarding that issue. To see the
other issue comment out lines 154-189 and uncomment lines 193-237 in
MyDocument.m
I also have the archive project here: http://www.dazys.com/Bug-1.zip
--
Michael
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
