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
