Re: FATAL Unlocking thread is not locking thread
Re: FATAL Unlocking thread is not locking thread
- Subject: Re: FATAL Unlocking thread is not locking thread
- From: OC <email@hidden>
- Date: Sat, 13 Dec 2014 03:05:25 +0100
Samuel,
On 12. 12. 2014, at 22:46, Samuel Pelletier <email@hidden> wrote:
> You are sure, after checked at least 3 times, that you are not using an EO from another EOEditingContext in this process?
About 33 times... though there still, of course, is a possibility I am overlooking something. I would be rather grateful if it was so, for it would explain the problem nicely and allow for an easy fix; but whatever I do, I can't find any such case :(
At the very least, whilst I did not log the EC of objects involved (alas), I _do_ log both System.identityHashCode and PK; and thus I can be pretty sure that the object whose storedValueForKey gets called and causes the problem (unlocking the OSC which was locked in another thread) has same PK, but different hash than the same object logged shortly before from a worker thread which uses the session default EC.
Which looks like a bad news, for it means that it very probably _is_ the local copy in the thread local EC :(
> You may also try to construct a dedicated EOF stack for the process to isolate it completely.
Thanks! I guess if the problem occurs again (and unless I find a simple culprit of using a session default EC in the thread somewhere), I'll have to try...
Of course, I've upgraded the logs, so if it happens again, I _shall_ know the EC involved :)
Thank you very much,
OC
> 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