On 28/09/2013, at 5:04 AM, Henrique Prange wrote:
> 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.
On 28/09/2013, at 12:52 AM, Jean-François Veillette
wrote:
> 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
> m
On 27 Sep 2013, at 21:34, Henrique Prange wrote:
> Hi Paul,
>
> On 26/09/2013, at 19:55, Paul Hoadley 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
>>
Hi Paul,
On 26/09/2013, at 19:55, Paul Hoadley 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
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
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/0
Hi Paul,
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.
2) Do not pass EOs to the background task. Onl
Hi Chuck,
On 26/09/2013, at 12:39 PM, Chuck Hill wrote:
> How about passing in an array of EOs as EOGlobalIDs and a dictionary of
> EOGlobalIDs to whatever prepared data (user info) you need?
That's a good idea. It still looks like I'll need to abandon the idea of
making it sufficiently gene
How about passing in an array of EOs as EOGlobalIDs and a dictionary of
EOGlobalIDs to whatever prepared data (user info) you need?
Chuck
On 13-09-25 7:41 PM, "Paul Hoadley" wrote:
On 25/09/2013, at 2:32 PM, Paul Hoadley
mailto:pa...@logicsquad.net>> wrote:
To be more specific, then, I'm impl
On 25/09/2013, at 2:32 PM, Paul Hoadley wrote:
> To be more specific, then, I'm implementing a new background task for the
> ERJasperReports.framework which I'm calling ERJRDataSourceReportTask. It's
> analogous to the existing ERJRFetchSpecificationReportTask, but takes an
> ERJRFoundationDa
Chuck forgot to hit Reply All...
On 25/09/2013, at 1:05 PM, Paul Hoadley wrote:
> I have a Callable task that runs in the background. It needs an array of EOs
> to produce a report. Is it sufficient to localInstance all of those EOs into
> their own newly-created EC just for the task, or _mu
Hello,
I have a Callable task that runs in the background. It needs an array of EOs
to produce a report. Is it sufficient to localInstance all of those EOs into
their own newly-created EC just for the task, or _must_ they be handed over to
the background task as EOGlobalIDs? (If the latter,
12 matches
Mail list logo
