• 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: Chuck Hill <email@hidden>
  • Date: Wed, 8 Nov 2006 11:26:37 -0800

Hi Fabrice,

On Nov 8, 2006, at 1:37 AM, Fabrice Pipart wrote:
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(session ().defaultEditingContext()) (which then locks the childEc and the default editing context right?)

Yes, locking the child locks the parent. Please note that the opposite is not true: locking the parent does NOT lock the children.



- my refreshing page does Session._awakeInContext which triggers ERXEC.lock on the default ec ----> deadlock ! The page does not refresh !


Correct.


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.

Yes, correct.


Why did not I think about it ! Thanks !

It is only obvious after the first time!


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...

The difference is that session().defaultEditingContext() won't get locked when you lock the child or parent.



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...

Exactly. In this case you probably don't want either ERXECs or the MultiECLockManger. The long request page is running outside of the RR Loop. In this case you are better off managing the locking yourself. Probably just lock on creation and unlock on save/cancel/ error will be fine.


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


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>)
 >Re: Locking and threads (From: Fabrice Pipart <email@hidden>)

  • Prev by Date: Re: Handy fault firing detection
  • Next by Date: Re: Somewhere a short howto for using JasperReports with WO?
  • Previous by thread: Re: Locking and threads
  • Next by thread: Oracle and NVARCHAR2 with WO/EOF?
  • Index(es):
    • Date
    • Thread