> 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
>
