Re: Mysterious EditingContext Swap
Re: Mysterious EditingContext Swap
- Subject: Re: Mysterious EditingContext Swap
- From: "Jerry W. Walker" <email@hidden>
- Date: Fri, 4 Aug 2006 10:44:31 -0400
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
On Aug 4, 2006, at 9:22 AM, Fabrice Pipart wrote:
Hi !
On Aug 4, 2006, at 1:43 PM, Jerry W. Walker wrote:
Hi, Fabrice,
On Aug 4, 2006, at 3:07 AM, Fabrice Pipart wrote:
On Aug 2, 2006, at 7:05 PM, Chuck Hill wrote:
On Aug 1, 2006, at 8:50 PM, Owen McKerrow wrote:
Nope, not paraphrasing. You can see the full error message at
bottom of the email.
The only time I have heard of the active editing context is for
a save.
All EOF operations are serialized. The active editing context
is the one that locked the object store (IIRC). You are not
locking your editing contexts properly. My guess is that this
is the root of your problem. Is this error consistent, or
somewhat random?
Chuck
I am experiencing exactly the same problem.
Here is my context :
WebObjects 5.2.4
Mac OS 10.4.7
MySQL 4.1.18
We are using a child editing context between some pages.
BTW : is it necessary to lock a child ec after creating it? (I
tried it did not change anything)
In a word, YES.
Did you lock the child editing context for all operations on its
EOs rather than just for saveChanges? The easiest safe way to do
this is to use MultiECLockManager by registering your new EC with
MultiECLockManager as soon as you create the EC.
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 ??
--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial
Strength Internet Enabled Systems
email@hidden
203 278-4085 office
_______________________________________________
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