On 27 Sep 2013, at 21:34, Henrique Prange wrote:

> Hi Paul,
> 
> On 26/09/2013, at 19:55, Paul Hoadley <pa...@logicsquad.net> wrote:
> 
>> 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 <hpra...@gmail.com> 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.
> 
> [1]http://en.wikibooks.org/wiki/WebObjects/Web_Applications/Deployment/Common_Pitfalls_and_Troubleshooting#Dealing_with_Deadlocks.2FApplication_Hanging
> 

A separate EOF stack for the background tasks would be better IMO.

Cheers,
Bogdan Zlatanov
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to