• 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
Re: generating response in different thread
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: generating response in different thread


  • Subject: Re: generating response in different thread
  • From: Paul Suh <email@hidden>
  • Date: Thu, 25 May 2006 23:19:29 -0400

Christian,

The problem that you're running into is that when you access a EO's values you're supposed to lock the EO's editing context first. The session's default editing context is locked and unlocked for you as part of the request-response loop, but if you're trying to access the EO's in another thread you're going to run into stalls while the thread waits for the EC lock. You're going to need to create a local editing context in your long response page and bring the necessary objects into it by using EOUtilities.localInstanceOfObject(...). You can then safely lock your local EC and bind to those objects in the long response page's thread.

A question that occurs to me is why are the bindings so slow? Is it because you are following many relationships and firing many faults, each of which is making a round trip to the database? If so, you might want to look at attaching prefetching key paths to your original fetch spec, so that you get all of the necessary snapshots into memory in one round trip to the database -- in which case firing the faults is lightning quick and does not require a round trip. I have had a page go from taking over 5 minutes to generate to under a second by putting in some prefetching key paths; instead of several hundred transactions to the database it took only one.

Hope this helps.


--Paul


Paul Suh http://www.ps-enable.com/
email@hidden (301) 643-1516




On May 25, 2006, at 11:47 AM, Christian Pekeler wrote:

I have a bunch of pages that can take a long time to generate. I'd like to show a WOLongResponsePage in the interim. The typical way of using WOLongResponsePage is to run the business logic or whatever is taking a long time in a different thread (kicked off by WOLongResponsePage.performAction()), and once done, generate the final page with the result of that expensive computation (with WOLongResponsePage.pageForResult(Object)).

Unfortunately, the pages I have to deal with can't be used with this pattern. They're slow because they contain thousands of bindings which each are partly responsible for the slowness. Getting all the values upfront at once would require me to rewrite the pages - something I don't have time for.

So what I'd like to do instead is (simplified):
  WOLongResponsePage.performAction() {
      slowPage.generateResponse();

I think I've figured out how to do WOLongResponsePage.pageForResult (the slow pages are basically display-only). My problem is calling generateResponse() from a new thread. Some bindings on the slow pages are hooked up to the session, and to objects in the session's defaultEditingContext causing all sort of issues that I'm having troubles tracking down. So, has anyone ever done this sort of thing and could give me any advice?

_______________________________________________ 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
References: 
 >generating response in different thread (From: Christian Pekeler <email@hidden>)

  • Prev by Date: Fwd: XCode 2.3 : so far so good - ummm...
  • Next by Date: wo desktop image
  • Previous by thread: generating response in different thread
  • Next by thread: Re: generating response in different thread
  • Index(es):
    • Date
    • Thread