• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Locking and threads
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Locking and threads


  • Subject: Re: Locking and threads
  • From: Fabrice Pipart <email@hidden>
  • Date: Wed, 8 Nov 2006 10:37:39 +0100


On Nov 7, 2006, at 6:59 PM, Chuck Hill wrote:


On Nov 7, 2006, at 4:10 AM, Fabrice Pipart wrote:

Yes sure !
I think I forgot to mention that my child ec was already created ;-)

As you have used it, that is the parent EC!  :-)

That's right ;-)
And childEc = new EOEditingContext(session().defaultEditingContext());


Actually here is what I want to : create a long response page in a wizard.
All the wizard pages use the same child ec (its passed through components).

All I want to do is use an editing context in the long response thread that does not commit its changes to the database directly.
That's why I use a child ec in the wizard pages : to be able to do a session().defaultEditingContext().revert();

And that is what is causing the deadlock I would guess.  Is your code equivalent to:

Here is where the deadlock comes from (I finally understood it) :
- my long task thread locks the new EOEditingContext(childEc) (which then locks the childEc and the default editing context right?)
- my refreshing page does Session._awakeInContext which triggers ERXEC.lock on the default ec ----> deadlock ! The page does not refresh !

EOEditingContext ec = new EOEditingContext(session().defaultEditingContext());

If so, that is not going to work with a long response sort of page.

You are going to need two new editing contexts:

EOEditingContext parent = new EOEditingContext();
EOEditingContext child = new EOEditingContext(parent);

The wizard can save the child, and at the end, something needs to save the parent.  You will be responsible for locking these editing contexts.

So, if I understand correctly you propose to use a child ec that does not have the default ec as parent but rather a new ec.
Why did not I think about it ! Thanks !

What difference is there switching from child = new EOEditingContext(ession().defaultEditingContext()); to child = new EOEditingContext(parent); ???
I can't see any but if the two exist...

And I would have some last questions to help me make things clear with locking and specially ERXEC :

- To lock correctly ec in R-R loops, I can use MultiECLockManger and lock in session's awake and sleep, but if I create my new ecs as ERXECs, do I need to do something else or will it be automagically locked and unlocked even if er.extensions.ERXEC.defaultAutomaticLockUnlock = false ?
- From what I understood, it just unlocks, so it still makes sense to use the MultiECLockManger right? For example to automatically lock my childEc in the wizard pages...

Thanks a lo for the help !

Fabrice


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



 _______________________________________________
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

  • Follow-Ups:
    • Re: Locking and threads
      • From: Chuck Hill <email@hidden>
References: 
 >Locking and threads (From: Fabrice Pipart <email@hidden>)
 >Re: Locking and threads (From: Alexander Spohr <email@hidden>)
 >Re: Locking and threads (From: Fabrice Pipart <email@hidden>)
 >Re: Locking and threads (From: Chuck Hill <email@hidden>)

  • Prev by Date: [OT] The omnigroup does not like me anymore
  • Next by Date: Re: running a perl script with RunTime.Exec causes perl script to die
  • Previous by thread: Re: Locking and threads
  • Next by thread: Re: Locking and threads
  • Index(es):
    • Date
    • Thread