I think I've narrowed this down a bit :-) If I add
NSNotificationCenter nc = NSNotificationCenter.defaultCenter();
nc.removeObserver(nested, EOObjectStore.ObjectsChangedInStoreNotification,
null);
Just before the last ec.saveChanges(), the save is successful. Looking in
ERXEC, I see
/**
* Overridden so add a bugfix from Lenny Marks
*/
@Override
public void _objectsChangedInStore(NSNotification nsnotification) {
ERXEnterpriseObject.FlushCachesProcessor.perform(this,
(NSArray) nsnotification.userInfo().objectForKey("objects"));
if (savingChanges) {
synchronized (queuedNotifications) {
queuedNotifications.addObject(nsnotification);
}
}
else {
super._objectsChangedInStore(nsnotification);
}
}
For background, here's the original thread from Lenny Marks
http://markmail.org/message/kqyvvptath2fp6ez
So it would seem that the nested ECs are sneaking past this fix and causing
havoc. I'm still not sure what about garbage collection triggers this, but I've
updated ERXEC so that nested ECs check to see if any of its parents are saving
before processing notifications. The test passes with that change in place.
I've got it up on the SmartHealth fork of wonder. If you guys are interested,
then give it a try and see if it works for you. There doesn't appear to be any
testing of nested ECs that I can see in ERXTest, but I don't think this will
have any negative consequences.
https://github.com/smarthealth/wonder/commit/bed35de926d0fe53c207b2fea7f5e3d1922d0ddb
I'm deploying this out to a dev server now to see if any more snapshots go
missing. If all goes well, I'll pull this change into the main wonder fork.
Ramsey
On Jun 12, 2012, at 2:22 PM, Alexis Tual wrote:
> I'm also very curious about Ramsey's investigations because when this bug
> happens, you have to basically toss your EC stack...
>
> Alex
>
> 2012/6/13 Calven Eggert <[email protected]>
> I'm very curious to see your findings. One of our WO apps have had this
> problem for years but it happens so infrequently that the users don't seem to
> be bothered. It bothers me though. argh.
>
>
> On 2012-06-12, at 11:47 AM, <[email protected]>
> <[email protected]> wrote:
>
>> Ah, so it's the garbage collection that's triggering it. I should have
>> known, given the looping worked for small values. This is good. I can
>> distill the failure down to a single pair of EOs using System.gc() now.
>> This should make it a lot easier to investigate.
>>
>> public void testNestedECs() {
>> try {
>> EOEditingContext ec = ERXEC.newEditingContext();
>> Company c = (Company) EOUtilities.createAndInsertInstance(ec,
>> Company.ENTITY_NAME);
>> c.setName("Name");
>> ec.saveChanges();
>> EOEditingContext nested = ERXEC.newEditingContext(ec);
>> Company nestC = c.localInstanceIn(nested);
>> Employee e = (Employee)
>> EOUtilities.createAndInsertInstance(nested, Employee.ENTITY_NAME);
>> e.setFirstName("First");
>> e.setLastName("Last");
>> e.setManager(Boolean.FALSE);
>> e.addObjectToBothSidesOfRelationshipWithKey(nestC,
>> Employee.COMPANY_KEY);
>> nested.saveChanges();
>> ec.saveChanges();
>> System.gc();
>> c.delete();
>> ec.saveChanges();
>> } catch (Exception e) {
>> e.printStackTrace();
>> Assert.fail(e.getMessage());
>> }
>> }
>>
>> Thanks Alexis,
>>
>> Ramsey
>>
>
>
> _______________________________________________
> 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/alexis.tual%40gmail.com
>
> This email sent to [email protected]
>
>
> _______________________________________________
> 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/rgurley%40smarthealth.com
>
> This email sent to [email protected]
_______________________________________________
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]
