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 threadI need to lock itMy 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.deThis email sent to [EMAIL PROTECTED]
Freeport & Soliversum Alexander Spohr [EMAIL PROTECTED] www.freeport.de _______________________________________________ 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]
