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: Anjo Krank <email@hidden>
- Date: Tue, 6 Oct 2009 20:08:03 +0200
Create a ERXQualifierTraversal, create a new EC, fault the EOs into it
while recombining the qualifier.
Cheers, Anjo
Am 06.10.2009 um 20:03 schrieb Kieran Kelleher:
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:
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