Re: mandatory relatoinship preventing deletion?
Re: mandatory relatoinship preventing deletion?
- Subject: Re: mandatory relatoinship preventing deletion?
- From: email@hidden
- Date: Tue, 21 Oct 2003 15:51:52 CDT
- Priority: 3 (Normal)
[demime could not interpret encoding binary - treating as plain text]
Well, this is some useful food for thought. Although I'm not sure what to
do next, but...
On Tue, 21 Oct 2003 12:43:01 -0700 Chuck Hill wrote:
> Wow, I can't think of what else that might be. Unless one of the bulk
> setXxxx(NSMutableArray aValue) methods is setting in an EO in the
> wrong EC and you are not checking that.
Yeah, indeed my setRelationshipName methods don't have these checks. I
hadn't added them because it was a pain, and as far as I know my code
never calls them, but I suppose I should add those checks just in case.
[Although it's unclear if it's a to-one or a to-many that's involved. The
problem area involves an exposed many-to-many join, so there are
relationships of both types involved].
>
> If a save fails due to an error during propagateDelete... you can
> pretty much consider the EC to be permanently gibbled. Yes, its a
> bug. Yes, I've reported this. Yes, Apple is aware. Maybe this will
> be fixed in 5.2.2 but I'm not holding my breath.
My main concern is stopping the failure in propagateDelete... the
failures I'm getting in propagateDelete should NOT be happening, they are
very mysterious. But I suppose if I can't do that, it would be nice to
recover.
> > If these two exceptions are related, it would be interesting, as
> they are
> > both my biggest annoyances right now. Hard to reproduce, can't
> figure out
> > what the heck is going on.
> >
> It sounds to me like they are related.
>
Well, thanks for the feedback. The cause of the problem(s) remains a
mystery to me.
> I've never seen the crossed-ec problem caused by anything other than
> programmer error. That is a weird one and probably the root cause.
So I've just go to do some more investigating to figure out WHERE the
cross EC happens. The tricky thing is that when you delete an EO,
notifications get sent to all the other ECs, and propagate delete happens
on them too. So the EO that's triggering this crossed-ec problem may NOT
even be in the same EC as the delete was requested on. It may be at the
end of a notification instead. In fact, I seem to see both situations.
I'm not CERTAIN it's a crossed EC problem. I'm certain it's generating
the sort of exception which one gets from a crossed EC (EO is not in
EODatabaseContext's active EC), but it's of course conceivable that a
differnet problem (perhaps related to an EOF bug) could trigger this
exception too.
Well, for the moment, I guess I'll continue putting all sorts of
conditional debug appendln's in my deployed code, to try and catch WHERE
the crossed-EC relationship set happens, assuming that is the problem.
> Trouble turning it on on Solaris or some other platform?
>
I don't believe I've tried on anything but Solaris. But I never could get
it to work. I didn't try very hard, becuase it seemed that in order to
turn on EOF lock warnings, I needed to turn on a HUGE amount of other EOF
debug output I didn't want, which I found frustrating. But I guess I'll
just need to deal with it. I think I do need to absolutely rule out EOF
lock problems.
See, while I can't reproduce the exception on demand, I CAN get the
exception to occur eventually, by futzing around enough in my
application. But I've only been able to get this to happen on a deployed
and in-use instance. I haven't even gotten it to happen on a negative
instance # instance on my deploy machine; only with real life in use
deployed instances. This does suggest that locking may be a culprit.
Okay, does anyone want to give me tried and true directions for turning
on EOF stack lock warnings on Solaris?
--Jonathan
_______________________________________________
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.