Re: generating response in different thread
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