Re: Avoiding expensive database roundtrips for enterprise objects
Re: Avoiding expensive database roundtrips for enterprise objects
- Subject: Re: Avoiding expensive database roundtrips for enterprise objects
- From: Paul Dunkler <email@hidden>
- Date: Fri, 27 May 2011 10:19:31 +0200
Am 26.05.2011 um 20:28 schrieb Chuck Hill:
>
> On May 26, 2011, at 9:03 AM, Paul Dunkler wrote:
>
>> nice - thank you for the hint. I tried it and i was successfull. But in addition to this fix, it would be nice to know why the default behaviour of the editingContext is to refault all objects on saveChanges()... maybe anyone can explain?
>
> That is not the default behavior. I don't see this happening in my apps. Can you post the stack traces?
Hi Chuck,
what dou you exactly want to have from me? I´m not really sure what you mean with stack traces in this case - no error is going to be produced - so there is not any stacktrace output produced. Or is there some magic parameter / log setting which let me see stack traces for direct action calls?
>
>
> Chuck
>
>
>> Am 26.05.2011 um 16:40 schrieb John Huss:
>>
>>> I would presume that this is happening in response to the EOObjectsChangedInStoreNotification. You can implement an EOEditingContext delegate and override editingContextShouldInvalidateObject to see where it is happening and prevent it if you want.
>>>
>>> John
>>>
>>> On Thu, May 26, 2011 at 9:16 AM, Paul Dunkler <email@hidden> wrote:
>>> Hey guys,
>>>
>>> we are currently developing a large webobjects (plus wonder of course) driven backend application. Every time a request comes in, we fetch a big set of data for the customer related to this request.
>>> In the following actions we add/edit/delete some of the data originally fetched from the database. At the end of each request, we do saveChanges() on the editing context which holds our Customer Object with all it's relationships.
>>> After that all, we put a list of all the current data in the request's response for delivering fresh informations to the client.
>>>
>>> The problem we get here is the following:
>>> At the point of the request, where the fresh data is packed for presenting it in the response, every access onto some of the attributes or relationships from our Customer object lead us to a roundtrip in the database. That is very expensive and it means, that our application is performing the same Queries at the start of the request and at the end of the request again...
>>>
>>> If my text was too complicated or incomprehensible, here is a short-termed explanation of what i wanted to describe:
>>> 1. Incoming request
>>> 2. Batch fetching of the complete Customer-Object with all it's relationships we want to access in the following code
>>> 3. saveChanges() (somewhere in the process)
>>> 4. Generating the response
>>> -> Every call to a getter method (attributes) of the eo cause a roundtrip to the database.
>>>
>>> We currently don't really know why this is happening. If we fetch an object, change it's data, than save it - and then call a method on the same object, why it has to do a new roundtrip to the database?
>>>
>>>
>>> I just tried it out in a short DirectAction to check the behaviour:
>>>> // WITH EDITING AN OBJECT
>>>> Thing aThing = Thing.fetchThing(this.editingContext, Thing.NAME.eq("foo")); // <-- db-roundtrip
>>>> System.out.println("first try: " + aThing.fooRelationshipArray());
>>>> aThing.setBar(11);
>>>> this.editingContext.saveChanges();
>>>> System.out.println("second try: " + aThing.fooRelationshipArray()); // <-- db-roundtrip
>>>> this.responseDictionary.setObjectForKey(aThing.bar(), "points");
>>>>
>>>> // WITHOUT EDITING AN OBJECT - WILL NOT DO A NEW ROUNDTRIP TO THE DATABASE
>>>> Thing aSecondThing = Thing.fetchThing(this.editingContext(), Thing.PRIMARY_KEY_IDENTIFIER, 47); // <-- db-roundtrip
>>>> System.out.println(aSecondThing.fooRelationshipArray());
>>>> System.out.println("third try: " + aSecondThing); // <-- no db-roundtrip
>>>> System.out.println("fourth try: " + aSecondThing); // <-- no db-roundtrip
>>>
>>>
>>>
>>> It would be very nice if you got any ideas to avoid this behaviour. Or some nice thinkings about doing it right :)
>>> I think this is a problem which can be solved - we browsed Webobjects Books / Tutorials / Mailing List History, but had no luck at all....
>>>
>>>
>>> --
>>> Mit freundlichen Grüßen / Kind regards
>>>
>>> Paul Dunkler
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>>
>>
>> Mit freundlichen Grüßen
>>
>> Paul Dunkler
>>
>>
>> <xyrality_logo_medium.png>
>>
>> -----------------------------------------------------
>> XYRALITY GmbH • Lerchenstraße 28a • 22767 Hamburg
>> Paul Dunkler • Softwareentwickler
>> Mail: email@hidden
>> Tel: +49 (0) 40 23 51 78 97
>> Mobil: +49 (0) 151 11624143
>> Fax: +49 (0) 40 23 51 78 98
>> Web: http://www.xyrality.com/
>> Registergericht: Hamburg HRB 115332
>> Geschäftsführer: Sven Ossenbrüggen & Alexander Spohr
>> -----------------------------------------------------
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> --
> Chuck Hill Senior Consultant / VP Development
>
> Come to WOWODC this July for unparalleled WO learning opportunities and real peer to peer problem solving! Network, socialize, and enjoy a great cosmopolitan city. See you there! http://www.wocommunity.org/wowodc11/
>
Mit freundlichen Grüßen
Paul Dunkler
-----------------------------------------------------
XYRALITY GmbH • Lerchenstraße 28a • 22767 Hamburg
Paul Dunkler • Softwareentwickler
Mail: email@hidden
Tel: +49 (0) 40 23 51 78 97
Mobil: +49 (0) 151 11624143
Fax: +49 (0) 40 23 51 78 98
Web: http://www.xyrality.com/
Registergericht: Hamburg HRB 115332
Geschäftsführer: Sven Ossenbrüggen & Alexander Spohr
-----------------------------------------------------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden