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.