Our app currently does not use any of the Wonder frameworks at all. (It's big and was written over 10 years ago) I'd like to use ERXEC.newEditingContext(), as well as some of the other Wonder goodies. I've never been able to get the ec locking right on my own.
I'd like to ease my way into this, so can I start with only using ERXEC.newEditingContext(), and not ERXApplication or ERXSession? (And leave my EOs as EOGenericRecords instead of ERXGenericRecords). Will it still lock properly for me? Also, is there a minimum requirement for the version of WO or the version of java if I want to use Wonder? We have several sites still running java 1.4 and WO 5.2. Also, Ransey mentioned that i cannot pass the ec off into a separate thread. If i only use it to fetch raw rows, is it still a problem? On Jun 15, 2012, at 8:15 PM, Ramsey Gurley wrote: > 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] >
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]
