That stack trace does not make much sense to me either. If it did not lock it, it should not be trying to unlock it. This is not documented unless you. Count disassembling the byte code. ;-). It looks like the CSV import is using Groovy. Could the Groovy / EOF integration being playing a part here?
Chuck ________________________________________ From: OC <o...@ocs.cz> Sent: December 11, 2014 1:54:23 PM To: Chuck Hill Cc: webobjects-dev@lists.apple.com Subject: Re: FATAL Unlocking thread is not locking thread On 11. 12. 2014, at 14:37, OC <o...@ocs.cz> 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 (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
