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 > > > > > > > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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]
