Re: Locking and threads
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