Hi !
I finally tried what you suggested. I added the MultiEcLockManager class to my project I added a MultiEcLockManager.lock call in my session awake I added a MultiEcLockManager.unlock call in my session sleep I have two pages that use my child ec. In page one I now have :
childEC = new EOEditingContext(session().defaultEditingContext()); ((Session) session()).ecLockManager().registerEditingContext(childEC);
In page two I now have :
childEC.saveChanges(); session().defaultEditingContext().saveChanges(); ((Session) session()).ecLockManager().unregisterEditingContext(childEC);
And I still end with (when calling saveChanges on my session editing context): java.lang.IllegalStateException: Cannot obtain globalId for an object which is registered in an other than the databaseContext's active editingContext, object: {values = {... mediaBookingCampaign = "<com.easyshadow.server.MediaBookingCampaign c597ef <EOTemporaryGlobalID: 0 0 -64 -88 41 22 0 0 7 -42 1 0 0 0 1 12 -25 -122 109 9 -48 10 51 69>>"; ...}; this = "<com.easyshadow.server.MediaBooking b243a2 <EOTemporaryGlobalID: 0 0 -64 -88 41 22 0 0 7 -42 2 0 0 0 1 12 -25 -122 109 9 -48 10 51 69>>"; }, databaseContext: [EMAIL PROTECTED], object's editingContext: [EMAIL PROTECTED], databaseContext's active editingContext: [EMAIL PROTECTED]
where [EMAIL PROTECTED] is my childEc [EMAIL PROTECTED] my session ec
Where do I make a mistake ? Please note that my application has other pages that use a child ec without any problem
And "One more thing ..." (it is the good day to say something like that !) : we actually realized that the child ec in those pages isn't absolutely necessary. And of course if we only use the session ec, it works fine. Could that be the cause of the problem? I am just trying to find out what the problem is because I think there might be other places in my code where it could happen and I would like to know what I am doing wrong.
Fabrice
On Aug 4, 2006, at 6:13 PM, Chuck Hill wrote:
On Aug 4, 2006, at 7:44 AM, 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.
It is impossible, or almost impossible, to lock and unlock an EC correctly in your component code. Don't even think about trying it.
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.
What Jerry said.
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. :-)
Darn. Too slow on the typing again. ;-)
Chuck
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
203 278-4085 office
_______________________________________________ Do not post admin requests to the list. They will be ignored. Help/Unsubscribe/Update your Subscription:
--
_______________________________________________ Do not post admin requests to the list. They will be ignored. Help/Unsubscribe/Update your Subscription:
www.easyshadow.com
International Corporate Consulting Palais de la Scala 1 avenue Henri Dunant Suite 1155 MC - 98000 Monaco
Skype: fabrice.pipart Tel. +377 97 98 21 04 (direct) Fax. +377 97 70 88 07
|
smime.p7s