Re: Yes, even one more concurrency question - relationship "freshness"
Re: Yes, even one more concurrency question - relationship "freshness"
- Subject: Re: Yes, even one more concurrency question - relationship "freshness"
- From: Chuck Hill <email@hidden>
- Date: Tue, 14 Aug 2007 09:03:49 -0700
Hi Miguel,
You do have all the fun. Must be nice in Alentejo this time of year...
On Aug 13, 2007, at 3:42 PM, Miguel Arroz wrote:
Hi!
Have you tried
a.removeObjectFromBothSidesOfRelationship( obj, "bs" );
Same result.
I thought so, but it was worth a try.
Have you made other changes in the EC? If not, ec.revert() should
handle all this much more cleanly.
I did! :( The problem is this: the user changes one object. Then,
I'm going to try to save the object, but the changes to that object
requires me to change some other objects and create some new ones
(the Bs).
If I have an OL failure, I must recalculate some stuff again, and
I have to delete and regenerate the Bs, because the number of Bs
needed, and their data, may be different, because they are based
not only on the object I'm changing, but also on the data I refault.
That eliminates that.
Does something else have a relation to the B entity?
B has two relationships. One of them is two-ways (from B to A),
and it also relates with other object, but one-way only (no inverse
relationship exists). I'll try to explicitly set that relationship
to null, although it appears to be null at the critical time.
I can't see how EOF is finding this object. Can you post the start
of the stack trace when this happens?
e only other thing that comes to mind is the ec.undoManager().
Perhaps this is getting called at somepoint and undoing your
deletion of the new B objects. ec.revert()...
I can't revert, unfortunately. :( If I can't find the problem, I
think I'll change this to a more simple way of doing things, where
I create the context, get the object, apply changes, try to do all
my neat stuff, and if the save fails, trash the EC, create a new
one, get the object, reapply changes, do all the neat stuff again,
and so on. That way I should have less problems, although it's not
so nice in terms of elegance (not that the currently solution is a
top model, but...).
:-)
BTW, on the next WOWODC (I *do* promise that the videos will be
recorded in a better way, I still kick myself every-time I think
about that), I suggest some sessions about concurrency. Lots of
them. I suspect there are tons of WO apps out there with hidden
problems. Or maybe it's just me.
I think there are a lot of applications our there with theoretical
problems. I am not sure that people find this to be a problem in
practice or, if they do, that they realize what happened. For many
of them concurrency is not a problem, users never edit objects that
other users can access. For may others, a "last in wins" approach is
just fine. It is definitely one of the unpolished areas of EOF.
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden