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 protected]<mailto:[email protected]>> wrote: On 8 Jan 2015, at 4:49 pm, Paul Hoadley <[email protected]<mailto:[email protected]>> 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. -- Paul Hoadley http://logicsquad.net/
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
