• 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: Deadlocks, editing context locking and network tasks
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Deadlocks, editing context locking and network tasks


  • Subject: Re: Deadlocks, editing context locking and network tasks
  • From: René Bock <email@hidden>
  • Date: Mon, 05 Sep 2016 08:34:59 +0000
  • Thread-topic: Deadlocks, editing context locking and network tasks

Hi Mark

> Am 03.09.2016 um 22:36 schrieb Mark Wardle <email@hidden>:
>
> Dear all,
>
> I’m debugging a deadlock and realise that I probably need to re-design some of my code logic.
>
> Am I right in saying…
>
> 1. For a background thread, it is appropriate to create a new editing context (ERXEC.newEditingContext(osc)) using a dedicated and new object store coordinator (created using osc = new ERXObjectStoreCoordinator()).

you should do that.

>
> 2. For a background thread, all such editing contexts should be lock()’ed and then unlock()’ed - unlocked in finally {} clause in case of uncaught exceptions. Automatic locking is only for ECs used within the R-R loop?

yes

>
> 3. But what should one do if, either during a background thread, R-R loop (direct action or component action), one locks an editing context, does some processing of objects within that context, makes a network call, and then does some more processing within that context. Should one simply lock() and then hope for the best, or unlock, do the network process and then re-lock at the end. Are there any issues running unlock() if the EC isn’t actually locked? What happens if that network call never returns?

You should handle network time-outs ;-)  How long may the remote call may take? Seconds, minutes or hours? If you have many background tasks waiting network I/O, you may run out of OSCs or memory..


>
> 4. Is locking an EC from a newly created OSC completely independent from all other OSC ECs?

If you lock en EC, the other OSC (and theire ECs) are not affected

> If that lock isn’t released for some time, does it matter?

see above.

>
> All advice appreciated,


By the way: there is a very helpful screencast on wocummunity:

http://www.wocommunity.org/podcasts/wowodc/2011/BackgroundTasks.mov


Best regards

René Bock

--
Phone: +49 69 650096 18

salient GmbH, Lindleystraße 12, 60314 Frankfurt
Main: +49 69 65 00 96 0  |  http://www.salient-doremus.de


 _______________________________________________
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: Deadlocks, editing context locking and network tasks
      • From: Mark Wardle <email@hidden>
References: 
 >Deadlocks, editing context locking and network tasks (From: Mark Wardle <email@hidden>)

  • Prev by Date: Re: Maven - <com.webobjects.appserver._private.WOComponentDefinition> No template found for component Main
  • Next by Date: Re: Maven - <com.webobjects.appserver._private.WOComponentDefinition> No template found for component Main
  • Previous by thread: Deadlocks, editing context locking and network tasks
  • Next by thread: Re: Deadlocks, editing context locking and network tasks
  • Index(es):
    • Date
    • Thread