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/archive%40mail-archive.com This email sent to [email protected]
