• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: continuing saga of weird EOF exceptions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

  • Prev by Date: Re: continuing saga of weird EOF exceptions
  • Next by Date: Re: db connect in session
  • Previous by thread: Re: continuing saga of weird EOF exceptions
  • Next by thread: to-many is null?
  • Index(es):
    • Date
    • Thread