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! :-)
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:
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.
HTH
Chuck
BTW : I left one point unclear in my first post.
When I say I get a deadlock its not exactly it.
As soon as my long response page locks its editing context (in the
separate thread), then the refreshing page (in a WorkerThread) is
not able to refresh anymore because it is stuck when awakening.
Fabrice
On Nov 7, 2006, at 1:00 PM, Alexander Spohr wrote:
public EOEditingContext(EOObjectStore parent)
Creates a new EOEditingContext object with parent as its parent
object store.
maybe that exerpt from the docs answers it: you create the child,
not the parent.
atze
Am 07.11.2006 um 12:07 schrieb Fabrice Pipart:
Hi all !
I am having troubles designing a specific need.
I would like to add a progress bar for long running tasks.
I found that ERXLongResponse and its task could be a good thing
for me (more flexible than the WOLongResponsePage).
Here is what I understood from such a process :
I need to create a new editing context in the performAction since
it runs in a separate thread
I need to lock it
My issue is that I want to do my long task in a child editing
context (I don't want to commit changes to the db but in the
child ec).
So I used this call :
EOEditingContext ec = new EOEditingContext(childContext);
But if I lock such an editing context, I get a deadlock when my
session is restored.
I am using MultiEcLockManager (at least its integrated in my code
in case I want to use it ;-) ) AND ProjectWonder
Since I use project wonder I think my ECs are ERXECs (my session
extends ERXSession)
I am a bit confused about all those locking issues.
I have nothing against just using ProjectWonder and its ERXEC, if
I do so, do I still need to lock/unlock the ec
(defaultEditingContext().lock() ?) in session's awake/sleep?
Would I have the same benefits as using MultiEcLockManager?
Does an ERXEC created from a ERXEC.newEditingContext(); call
needs locking if its used in a separate thread ?
Is there anything different if the call is ERXEC.newEditingContext
(childContext); ?
In general, when does an EC needs to get locked manually
(supposing we have er.extensions.ERXEC.defaultAutomaticLockUnlock
= false) ?
Thanks to anyone who could 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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/atze%
40freeport.de
This email sent to [EMAIL PROTECTED]
Freeport & Soliversum
Alexander Spohr
[EMAIL PROTECTED]
www.freeport.de
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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/chill%
40global-village.net
This email sent to [EMAIL PROTECTED]
--
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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
