• 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: FATAL Unlocking thread is not locking thread
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FATAL Unlocking thread is not locking thread


  • Subject: Re: FATAL Unlocking thread is not locking thread
  • From: Samuel Pelletier <email@hidden>
  • Date: Fri, 12 Dec 2014 16:46:33 -0500

OC,

You are sure, after checked at least 3 times, that you are not using an EO from another EOEditingContext in this process?

You may also try to construct a dedicated EOF stack for the process to isolate it completely.

Samuel

Le 2014-12-11 à 13:54, OC <email@hidden> a écrit :

> On 11. 12. 2014, at 14:37, OC <email@hidden> wrote:
>
>> it was again caused by/reported in a background thread which imports CSV, exactly like before -- so it seems highly probable the culprit would be _somewhere somehow_ in the concurrent access of the background thread and the main one...
>
> I wonder... is it somewhere documented when exactly WebObjects lock/unlock the OSC?
>
> I must be missing something obvious, but to be quite frank, I don't really get why EOCustomObject.willReadRelationship does unlock the OSC. My (self-evidently wrong) intuition would say they should either not do anything with locks in there, or, perhas, they should lock in willRead, not unlock...
>
> Far as I've been able to find the culprit so far, it looks like
>
> (a) somewhere in EOEditingContext.saveChanges() the OSC gets locked
> (b) in which moment the background task gets to read EOCustomObject.storedValueForKey for an EO (in its own editing context)...
>
> ... and that boils down through EOCustomObject.willReadRelationship to unlock the OSC (without trying to lock it, which would simply sleep the thread). Which causes the exception.
>
> Thanks,
> OC
>
>
> _______________________________________________
> 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


 _______________________________________________
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: FATAL Unlocking thread is not locking thread
      • From: OC <email@hidden>
References: 
 >FATAL Unlocking thread is not locking thread (From: OC <email@hidden>)
 >RE: FATAL Unlocking thread is not locking thread (From: Chuck Hill <email@hidden>)
 >Re: FATAL Unlocking thread is not locking thread (From: OC <email@hidden>)
 >Re: FATAL Unlocking thread is not locking thread (From: OC <email@hidden>)
 >Re: FATAL Unlocking thread is not locking thread (From: OC <email@hidden>)

  • Prev by Date: RE: Deploying issue
  • Next by Date: Re: FATAL Unlocking thread is not locking thread
  • Previous by thread: RE: FATAL Unlocking thread is not locking thread
  • Next by thread: Re: FATAL Unlocking thread is not locking thread
  • Index(es):
    • Date
    • Thread