• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Avoiding expensive database roundtrips for enterprise objects
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Avoiding expensive database roundtrips for enterprise objects


  • Subject: Avoiding expensive database roundtrips for enterprise objects
  • From: Paul Dunkler <email@hidden>
  • Date: Thu, 26 May 2011 16:16:47 +0200

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

  • Follow-Ups:
    • Re: Avoiding expensive database roundtrips for enterprise objects
      • From: John Huss <email@hidden>
  • Prev by Date: Re: WOGWT adaptor
  • Next by Date: Re: John Huss, are you teasing me?
  • Previous by thread: FW: John Huss, are you teasing me?
  • Next by thread: Re: Avoiding expensive database roundtrips for enterprise objects
  • Index(es):
    • Date
    • Thread