Hi, Fabrice (and Mike),
I've been looking off and on for an old message about locking editing
contexts by Ben Trumbull of Apple since I first saw your question.
It's an excellent review of WHY editing contexts must be locked
whenever their EOs are referenced (not just when the EC is referenced
directly).
http://lists.apple.com/archives/webobjects-dev/2004/Dec/msg00255.html
Do a search in the (rather long) message for the text string: "In
reading a discussion thread about ERXEC recently," and start reading
there.
Happy reading (it's worth it).
Mike:
I don't know if Ben Trumbull agreed to allowing his messages to be
included in our WO Wiki, but if so, this would be an excellent
explanation to put there. The question of how to lock a user created
EC and how much locking is necessary comes up often on the lists. His
is one of the most succinct answers I've seen that touch all the bases.
Regards,
Jerry
On Aug 4, 2006, at 11:32 AM, Fabrice Pipart wrote:
On Aug 4, 2006, at 4:44 PM, Jerry W. Walker wrote:
Hi, Fabrice,
I did lock the child EC in the whole book method :-(
I also tried locking the childEc everywhere it was called
Though I don't think my problem is related to locks, I think its
time to give a look to that MultiECLockManager class
Where did I put my Practical WebObjects book ? ;-)
So where can that problem come from ??
The EOEditingContext is referenced in lots of ways that are not
particularly visible or intuitive. The basic rule seems to be, if
you're interacting with an EO, then that EO's editing context
better be locked whether you're directly referencing the editing
context or not.
It is NOT SUFFICIENT to lock the editing context only when it is
called. It is also not a good idea to lock/unlock the editing
context in a component's awake and sleep methods, because it is
possible that awake will be called more often than sleep.
MultiECLockManager was created to make locking multiple user
created editing contexts easy. Once it's set up, it's nearly as
easy as using the Session's defaultEditingContext. Basically, all
you do (after setting it up) is a two step process:
EOEditingContext myEC = new EOEditingContext();
((Session)session()).lockManager().registerEditingContext(ec);
That's it! Now you're safe. The MultiECLockManager locks all your
registered editing contexts in the Session's awake() method and
unlocks them in the Session's sleep() method.
Anything less than this when using editing contexts that you
created is generally begging for deadlock problems.
Setting up MultiECLockManager is a bit harder, but is not overly
difficult and is well documented in the downloaded package.
I can provide you with notes if you download it and it still
doesn't make sense.
If that doesn't do the job, I'm always open to a (full expenses
paid) consulting trip to Monaco to give you a hand. :-)
Regards,
Jerry
OK
So now it is clear that I HAVE TO (not should) give a look to that
MultiECLockManager I heard of many times before.
Thanks a lot for the clear answer !
I really think this mailing list is the best part of WebObjects
Thanks to all of you that read this email !
Jerry I ll come back to you if I really don't understand something !
Concerning the trip to Monaco I ll ask my boss first ;-)
I will keep you updated if MultiECLockManager solves my problem (I
will implement it Monday)
Fabrice
--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial
Strength Internet Enabled Systems
[EMAIL PROTECTED]
203 278-4085 office
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to archive@mail-archive.com
