Re: continuing saga of weird EOF exceptions
Re: continuing saga of weird EOF exceptions
- Subject: Re: continuing saga of weird EOF exceptions
- From: Chuck Hill <email@hidden>
- Date: Mon, 11 Aug 2003 13:17:35 -0700
- Organization: Global Village Consulting, Inc.
I've trimmed the message as this list is very fussy about message
size. You might also get better responses from the Omni EOF list.
Jonathan Rochkind wrote:
I am on Solaris, but I'm trying to do it in code. In my app constructor.
But it doens't seem to have any effect. Very mysterious. Soon I'll have
to spend the time to investigate in depth.
One thing to try is to call some other NSLog message (even just print
a message) before setting the levels and groups. If it is a static
initialization bug this may avoid it. I assume you are just doing this:
NSLog.allowDebugLoggingForGroups(NSLog.DebugGroupMultithreading);
The exception below is what I would expect to see if you have a
relationship from an eo in one ec to an eo in another ec.
>>
...I've never
seen that exception from a cross-EC relationship; similarly obscure
exceptions, yes, not this exact one though.
That exception is exactly what creating a relationship from an eo in
one ec to an eo in another ec produces when the ec is saved. Perhaps
you forgot a call to localInstnaceOfObject somewhere? We use Design
by Contract to add a contract to all methods setting a relationship to
ensure editingContext() == relatedObject.editingContext()
From the stack trace it appears that this error may be getting raised
from an ec other than the one you are saving in.
I'm not sure that's so; I was trying to decide whether that was the case
or not, but from the stack trace, couldn't figure it out. What makes you
say this?
EOEditingContext.java 3438 _processObjectStoreChanges
Method.java NA invoke
NSSelector.java 354 invoke
NSSelector.java 108 _safeInvokeSelector
EOEditingContext.java 4660 _sendOrEnqueueNotification
EOEditingContext.java 3500 _objectsChangedInStore
The last two lines might be in different ecs. Some of the others too.
You can see the notifications getting sent. It is impossible to
determine which object is which in the trace. I certainly can't. I
expect that the exception *is* getting raised from the ec that is
saving but there is a chance that it is not.
It does seem to have something to do with delete rules
(propagateDeleteWithEditingContext). The object being deleted has a
'nullify' rule on one of it's relationships.
>
"Nullify disassociates all destination objects from the source object
by removing references to them. So, when an Agent object is deleted,
its related Customer objects are not deleted but the Customer objects
references to Agent are nullified (the entry in the join table is set
to null)."
As a result of the delete,
inside propagateDelete..., EOF seems to be going to the destination of
this relationship, and then trying to remove the deleted object from the
reciprocal relationship.
>
Yes, as described above.
> In the original EC, or some other EC, I'm not sure.
My expectation is the original but I'm not 100% clear on how such
changes are propagated to the other editing contexts holding the same
object.
While this makes sense because of the delete rule---I didn't think
EOF ever did that!
There may have been bugs in the past but it works now.
In fact, I'm used to having to manually remove an
object about-to-be-deleted from a relationship before deleting it,
despite the 'nullify' delete rule. My experience has been that even with
the delete rule, you've got to manually remove it yourself.
I don't recall that but I may be wrong.
Hmm, am I doing more work than I need to? Does EOF take care of
removing a deleted object from relationships, if the delete rule is set
appropriately (nullify?). Is it supposed to?
Yes it does and is supposed to.
I'll also note that when an ec raises an exception while processing
deletes:
...
That its internal state is totally trashed. To be precise it is
undone several levels too far while recovering from the exception.
Yes, I noticed that. The EC was indeed totally horked. [Have you filed
a bug on this?]
Yes and with a trivial iron-class reproduction case.
Well... this exception is just in my logs once; hopefully it won't come
back. (Yeah, right).
:-)
Chuck
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
Progress is the mother of all problems.
- G. K. Chesterton
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.