Re: Clarification on passing EOs to background threads
Re: Clarification on passing EOs to background threads
- Subject: Re: Clarification on passing EOs to background threads
- From: Henrique Prange <email@hidden>
- Date: Fri, 27 Sep 2013 16:34:48 -0300
Hi Paul,Hi Henrique,
Thanks for your input. Just out of curiosity, can I ask you to expand on a few points? (My original problem is solved—I'll just have to do the report creation in a less general way. But I think it's interesting to get to the bottom of the received wisdom on this issue.) On 27/09/2013, at 1:55 AM, Henrique Prange < email@hidden> wrote: I've refactored the report generation in one of applications lately to use a background task. A few lessons that I learned:
1) Do not create the editing context you're going to use in the background task during the request-response cycle.
So this would presumably include creating it in the constructor of the Callable class. What are the risks here?
I think it's a better idea to create the editing context in the run method before you start the report generation, not in the constructor.
The Callable constructor is invoked during the request-response cycle which means your editing context is going to be tied to the request thread. Wonder applications clear the thread storage and unlock all editing context related to the request thread at the end of the request-response cycle. This kind of cleanup can happen before your background has finished processing and then you have all sort of problems. 3) Do not reference the WOSession, WORequest, WOContext from the background task.
What are the risks here?
This can be risk. Wonder usually warns you in case you try to access the session or context from background threads. The problem is related to the fact that session access in WebObjects is single-threaded [1].
I didn't try to pass a session or context as a parameter to the Callable. Anyway, it isn't a good idea too. 5) You can pass a Map as parameter when generating Jasper reports. I don't how this could relate to your need to perform a dictionary preparation.
The preparation step is not an issue—I'll just move that into the background as well. (Obviously one could make a pretty good case that that's where it should be done anyway.)
I also had trouble locking the editing context in the background task, but I have no recommendation on this subject. You must check how your application behaves.
Interesting. What did you find?
Locking the editing context caused the application to stop handling requests while the report was generated. Not the expected result for a background job. :) The problem is related to the single EOF stack as explained by Jean-François.
Cheers,
Henrique |
_______________________________________________
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