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 19:59:14 +0200
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