Re: Long response page to hide page component generation time
Re: Long response page to hide page component generation time
- Subject: Re: Long response page to hide page component generation time
- From: Chuck Hill <email@hidden>
- Date: Thu, 08 Jan 2015 18:59:39 +0000
- Thread-topic: Long response page to hide page component generation time
|
The one problem you will run into is that the session and related ECs are not locked. You could refactor the page to take the user etc from other thread locals, pass them in and use localInstance EOs in an EC unique to the background thread. If you do
that and don’t touch session stuff in the background thread you should be OK.
Chuck
On 2015-01-07, 11:11 PM, "Paul Hoadley" wrote:
On 8 Jan 2015, at 5:12 pm, Paul Hoadley < email@hidden> wrote:
On 8 Jan 2015, at 4:49 pm, Paul Hoadley < email@hidden> wrote:
Calling generateResponse() and appendToResponse() on the report page both work in as far as they clearly spend the rendering time I'm expecting before returning from call(), but then my IERXPerformWOActionForResult controller class hands the page back from
its performAction() method, the rendering starts again from scratch on its way to the browser. Is there a way to achieve what I want here?
It seems there might be. Instead of discarding the generated WOResponse and returning a WOComponent, I can return the WOResponse and get quite close to what I was envisaging.
Except that I'm getting the feeling I'm playing with fire here. Generating the WOResponse in the background like this is causing complaints:
WARN ERXThreadStorage - The object for key 'session' was inherited from the parent thread. The usage of inherited objects that are a subclass of 'WOSession' can cause problems.
Indeed, there certainly is a problem, in that the session doesn't contain the logged-in user, so the report is being rendered with the wrong page wrapper. I was getting a bad feeling about all this, then I dug up an ancient thread in which Chuck and Guido
pretty much said "Don't do that!" and now I'm getting a _really_ bad feeling about this.
(Is there a completely different idiom I've overlooked?)
I'd still be interested to know this, though.
So, hit me with it.
|
_______________________________________________
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