You might consider using a brand new EOF stack (create a new Object Store Coordinator) for the background task. The advantage would be that you are the only on using the database connection, no jdbc locking problem with the main thread. The disadvantage is that you do not share the snapshot, so that even with a fetch from global id you will go down to the database since your snapshot cache is still empty.
As a generic way of doing, I would seriously consider going that route. To make it easier to work with, I would have an api on the background task object to give you the editing context for that specific background task, then (from your main thread) you can fill it up, prepare, fetch, do whatever, then when you really detach the background thread (the main thread no longer have pointer to that editingContext), it is really independent and has no impact on the main thread (you are safe). If you want to be « generic » and allow your object to be called while processing the report is going on, you could make an api where the background task invoke a « target » with an « action » (remember something?) that you gave it first. That way, you could (by giving the right « target ») access the context that triggered the report. Le 2013-09-26 à 18:55, Paul Hoadley <pa...@logicsquad.net> a écrit : > 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? > >> 3) Do not reference the WOSession, WORequest, WOContext from the background >> task. > > What are the risks here? > >> 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? > >> In the end, we have created a project (that is probably going to became open >> source) to handle the report generation. You can take a look here [1] for >> some inspiration related to Jasper data sources. Please, be gentle. The code >> is available but it's not completely polished. :) >> >> [1]https://github.com/hprange/woreports/tree/master/src/main/java/com/woreports/jasper > > Thanks a lot. I'll take a look. > > > -- > Paul Hoadley > http://logicsquad.net/ > > > > _______________________________________________ > 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/jean_francois_veillette%40yahoo.ca > > This email sent to jean_francois_veille...@yahoo.ca
_______________________________________________ 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
