Re: Passing an EOFetchSpec (having KeyValueQualifiers with EO references) to a background task....
Re: Passing an EOFetchSpec (having KeyValueQualifiers with EO references) to a background task....
- Subject: Re: Passing an EOFetchSpec (having KeyValueQualifiers with EO references) to a background task....
- From: Kieran Kelleher <email@hidden>
- Date: Tue, 6 Oct 2009 14:03:33 -0400
That's the concern ...... I usually pass GIDs to background tasks,
however in this case, I want to pass an EOFetchSpec to a background
task. So any suggestions on how to cleanly deal with that situation?
Regards, Kieran
On Oct 6, 2009, at 1:59 PM, Anjo Krank wrote:
When you have safelocking on, the EC gets locked and stays locked.
So you session won't be able to access it (if your task is an
ERXRunnable, it not, it's locked/unlocked on demand) and if you have
other locks, too, this might open you to deadlocks.
Cheers, Anjo
Am 06.10.2009 um 19:49 schrieb Kieran Kelleher:
So I have a Callable task that takes an EOFetchSpec. The FetchSpec
is built in the regular R-R context, passed to the Callable and the
Callable is dispatched. The Callable uses the FetchSpec to fetch
the objects in ots own background EC and perform the processing
task. The concern I have is that the qualifier in the EOFetchSpec
will probably have some key value qualfiers where the "value" is an
EOEnterpriseObject, so I am concerned about EditingContexts.
Specifically I am using Wonder's safelocking ERXEC's everywhere, so
I know that when the EOFetchSpec and its Qualifier(s) are touched
in the background thread, those EOKeyValueQualifier value EO ivars
will be in an unlocked ec. What is the best way to elegantly handle
this?
(1) Can those EO object references be converted to faults which in
turn are used in the qualifier and fetchspec construction? ......
or (2) should I just Serialize the fetchspec before passing to the
background thread and deserialize it there? ..... or (3) stuff
those EO values into the Callable's editing context before
constructing the qualifier (seems ugly)? ..... or (4) ......?
I had thought EOQualifier might be clever enough to just store
globalIDs of EOs passed in the value param of the constructor, but
Jad indicates otherwise.
Any suggestions?
-Kieran
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
@krank.net
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden