Chuck,
On 27. 2. 2015, at 23:25, Chuck Hill <ch...@gevityinc.com> 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?
===
// 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.
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 (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
