Which is handled automagically by ERXEC if you use wonder :-) So always do
EOEditingContext ec = ERXEC.newEditingContext(); And as long as you don't try to pass the ec off to a background thread, you should be fine. Make sure you aren't doing new EOEditingContext() anywhere. On Jun 15, 2012, at 4:37 PM, John Larson wrote: > always lock, try, finally unlock. Always. > > Always. > > John > > Sent from my iPhone > > On Jun 15, 2012, at 11:33 AM, doug andrews <[email protected]> > wrote: > >> OK. I will look into the locking. >> Back to the commandments. >> >> Thanks. >> >> >> On Jun 15, 2012, at 12:11 PM, Chuck Hill wrote: >> >>> Hi Doug, >>> >>> On 2012-06-15, at 8:50 AM, doug andrews wrote: >>> >>>> OK, I'm not sure why this works, but it seems to patch the problem. >>>> >>>> I have a to one relationship between the CUSTOMER and ADDRESS table. >>>> (Every customer has one mandatory address.) >>>> Both Address and Customer have custom entity classes. (Customer.java and >>>> Address.java.) >>>> The relation in the model for the customer entity is called "address". >>>> There is a non-null field in address called "zip". >>>> >>>> I have an Customer EO variable called custEO. >>>> >>>> Sometimes the line below will fail with a null pointer. >>>> Only sometimes, when the app is busy with 80 or more users. >>>> >>>> System.out.println(custEO.address().zip()); >>>> >>>> But these lines won't. >>>> >>>> Address addEO = custEO.address(); >>>> System.out.println(addEO.zip()); >>>> >>>> Does anyone know why this would be? >>> >>> My best guess would be lack of proper EOEditingContext locking. >>> >>> Second guess would be lack of property EODatabaseContext or below locking >>> (best to lock the root object store if you want to be safe). >>> >>> >>>> I'd like to fix this in my entity classes instead of patch the code >>>> everywhere the key path goes more that one deep. >>> >>> Speaking from experience :-), that won't work. You are just addressing the >>> symptom. Patch all of these and the problem will then pop up elsewhere. >>> >>> Back to the commandments. >>> >>> >>> Chuck >>> >>> >>>> On Jun 9, 2012, at 9:00 PM, doug andrews wrote: >>>> >>>>> I think we're breaking one or more commandment. >>>>> I see if that fixes our issue. >>>>> Thanks. >>>>> >>>>> >>>>> On Jun 8, 2012, at 8:34 PM, Chuck Hill wrote: >>>>> >>>>>> Hi Doug, >>>>>> >>>>>> >>>>>> On 2012-06-08, at 9:35 AM, doug andrews wrote: >>>>>> >>>>>>> Most of my entities are of class EOGenericRecord. >>>>>>> I do have a few custom entity classes that extend EOGenericRecord. >>>>>> >>>>>> Either your app is really simple, or you are doing it wrong. :-) >>>>>> >>>>>> >>>>>>> Sometimes, not always, the accessor methods for the "to one" >>>>>>> relationships return null, even though I know the relationship exists. >>>>>>> This usually only occurs when the app has 70 or more sessions running. >>>>>> >>>>>> That sounds more like you are breaking EOF commandments and getting EOF >>>>>> state corruption due to concurrency conflicts. >>>>>> >>>>>> >>>>>>> The code for these custom entities was generated by the old EOModeler >>>>>>> app. >>>>>>> They simply return storedValueForKey. >>>>>> >>>>>> That sounds correct. >>>>>> >>>>>> >>>>>>> The foreign key of the relationship is marked as "not null" in the >>>>>>> model, but the relationship is marked as "optional". I know this is >>>>>>> probably wrong, but the old EOModeler app let you get away with this, >>>>>>> and i'm sure stuff would break if i changed it now. >>>>>>> >>>>>>> To get the related entity from an EO that is of type EOGenericRecord, I >>>>>>> simply use valueForKey, and this never seems to return null. Since >>>>>>> this always works, should my accessor methods in my custom entity >>>>>>> classes return valueForKey instead of storedValueForKey? Would that >>>>>>> fix my problem? >>>>>> >>>>>> >>>>>> No, that will cause infinite recursion as valueForKey will call your >>>>>> accessor methods which will call valueForKey which will call.... >>>>>> >>>>>> >>>>>> >>>>>> Chuck >>>>>> >>>>>> >>>>>> -- >>>>>> Chuck Hill Senior Consultant / VP Development >>>>>> >>>>>> Practical WebObjects - for developers who want to increase their overall >>>>>> knowledge of WebObjects or who are trying to solve specific problems. >>>>>> http://www.global-village.net/gvc/practical_webobjects >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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/dandrews%40mediaspansoftware.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/chill%40global-village.net >>>> >>>> This email sent to [email protected] >>> >>> -- >>> Chuck Hill Senior Consultant / VP Development >>> >>> Practical WebObjects - for developers who want to increase their overall >>> knowledge of WebObjects or who are trying to solve specific problems. >>> http://www.global-village.net/gvc/practical_webobjects >>> >>> >>> >>> >>> >>> >>> >>> >> >> _______________________________________________ >> 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/the_larsons%40mac.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]
