Re: in another EC, when objects transferred through GIDs, owning relationship does not delete objects?!?
Re: in another EC, when objects transferred through GIDs, owning relationship does not delete objects?!?
- Subject: Re: in another EC, when objects transferred through GIDs, owning relationship does not delete objects?!?
- From: OC <email@hidden>
- Date: Sat, 28 Feb 2015 00:49:06 +0100
Chuck,
On 27. 2. 2015, at 23:25, Chuck Hill <email@hidden> 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >in another EC, when objects transferred through GIDs, owning relationship does not delete objects?!? (From: OC <email@hidden>) |
| | >Re: in another EC, when objects transferred through GIDs, owning relationship does not delete objects?!? (From: Chuck Hill <email@hidden>) |
| | >Re: in another EC, when objects transferred through GIDs, owning relationship does not delete objects?!? (From: OC <email@hidden>) |
| | >Re: in another EC, when objects transferred through GIDs, owning relationship does not delete objects?!? (From: Chuck Hill <email@hidden>) |
| | >Re: in another EC, when objects transferred through GIDs, owning relationship does not delete objects?!? (From: OC <email@hidden>) |
| | >Re: in another EC, when objects transferred through GIDs, owning relationship does not delete objects?!? (From: Chuck Hill <email@hidden>) |