Hi, On 2015-02-27, 3:49 PM, "OC" wrote:
Chuck, On 27. 2. 2015, at 23:25, Chuck Hill <[email protected]<mailto:[email protected]>> wrote: You can pass in EOs *if* you don't keep a reference to them (e.g. If you just localInstance them and then discard the reference before the thread runs as you are doing). Holding references is problem as then two threads can cause changes, get hung up on locks etc. Hmmm, I might be again overlooking something of importance, but... given the original objects are in the session's default EC, I think there's no point in flushing the references, for whenever I get the object again (e.g., through a relationship, or through a fetch, whatever), due to uniquing I'll get again the same reference, will I not? I mean you can't stash the EO in the EC that your background thread does NOT own (e.g. The session's default editing context) in an ivar in the background thread. That is the danger of passing in an EO - someone will do that and then you have two threads touching the session's default EC. I see, but that was -- unless I'm blind -- all right in my original code, was it not? Yes, as the eo never escaped the scope of the method creating the background thread. It is holding references into the run() method that will result in problems. === // this method gets called in worker thread of R/R loop ... static ERXLongResponseTask csvTask(EOEnterpriseObject ownerEO) { // ... and gets local EO in session default EC ... ERXEC ec=ERXEC.newEditingContext() ec.lock() // do I really need to lock here? try { ownerEO=ownerEO.localInstanceIn(ec) // ... which it turns to thread's EC's EO ... } finally { ec.unlock() } def task=new ImportCSVTask(ownerEO:ownerEO) // ... sent to the background thread: it never saw the original local one task.start() task } === That is fine. I was wondering if you had code in validateForDelete that might be fetching or otherwise altering the object graph and confusing the EOF state. Hmmm... wait a moment. Perhaps my old fixArchivedButReallyUnchangedItemsFromSnapshot() was called in validateForSave, for my previous tests were in the old code, before I fixed the fix outta validation code! Let me re-test now, when I've cut the thing out... alas, it did not help. But. It being the week end and me having at least some time free, I've played with the thing further. I've found that the GIDs are _not_ the culprit actually; the problem happens with localInstancesIn just as well -- _presumed I call changesFromCommittedSnapshot_[*]. Triple Wow. Ah, Schrödinger's EOF. :-P Observing some things can materially change the state of EOF. Calling this method calls ec.committedSnapshotForObject() which causes the EC to record the committed snapshot for the object at that point in time. Normally this is done only at the point the EO first changes. Good fun! Chuck The following code: === def ec=ERXEC.newEditingContext(),ec2=ERXEC.newEditingContext() ec.lock(); ec2.lock() // pbbly superfluous, but you said this prevents lots of hidden surprises :) def eo=EOUtilities.objectWithPrimaryKeyValue(ec,'DBAuction',1000004) def records=eo.importedRecords() def r1=records[0],r2=records[1] r1.removeObjectFromBothSidesOfRelationshipWithKey(eo,'auction') ec.saveChanges() def eo2=eo.localInstanceIn(ec2),r22=r2.localInstanceIn(ec2) //eo2.changesFromCommittedSnapshot() // WHAT THE?!? r22.removeObjectFromBothSidesOfRelationshipWithKey(eo2,'auction') ec2.saveChanges() === works properly, i.e., it DELETEs twice. As soon as I remove the comment-out at the WHAT THE line, i.e., as soon as "eo2.changesFromCommittedSnapshot()" gets called, I get DELETE/UPDATE (to null). Comment the line out again, two DELETEs are back. This gets curiouser and curiouser. Do you have any idea what the b. H. happens there? Or at least, what would you recommend I should try now, so that the culprit is found? Thanks and all the best, OC [*] What mislead me were my overridden toString's, in which I use changesFromCommittedSnapshot to print out the edited state.
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
