Re: EOF / multithreading app design question
Re: EOF / multithreading app design question
- Subject: Re: EOF / multithreading app design question
- From: Lachlan Deck <email@hidden>
- Date: Wed, 2 Dec 2009 15:47:55 +1100
On 02/12/2009, at 3:26 PM, Ken Anderson wrote:
> I could certainly copy them, but that would require another EC, my option #2...
It's an ec per thread. Shouldn't be a problem.
> There's also another downside I forgot to mention with plan #2 - there's interim data stored in all of these EOs that would need to be centrally accessed...
Accessed how? Notifications? If this interim data is saved to the db first(?) then just refault the eo in the other/main thread after receiving the relevant notification.
> which means that even if I did copy all the EOs, I would have to find a way for them to share results.
>
> On Dec 1, 2009, at 9:43 PM, Lachlan Deck wrote:
>
>>> All,
>>>
>>> I'm trying to decide on the best approach to something, and I'd like you guys to weigh in on possible options I might be overlooking.
>>>
>>> I have an application that does a lot of back-end processing. It has no UI (web or otherwise) to speak of.
>>>
>>> A large structure of EO's is built up that handles processing of price data as it arrives on an ActiveMQ queue. The EOs are all related in a pretty big object graph, so it's really convenient to have all this processing built right into the EOs.
>>>
>>> So - here's the problem. Once the whole structure gets initialized, there's hardly any database access. The structure is in place, and except for saving new price data, not much database interaction occurs. However, to be safe, I really need to have the EC locked - especially in the beginning when many faults are firing.
>>>
>>> At the moment, the whole thing is single threaded, since I lock the EC that all the objects are in, then push the one price in. Different things get computed, prices pop out, and then I process then next incoming price on the queue.
>>>
>>> Except for locking the editing context, the entire structure could easily be multi-threaded, allowing me to handle more than one price at a time. This would be a significant benefit, since there's a decent amount of processing that goes on for each incoming price, and we're running on an 8 processor machine.
>>>
>>> To multi-thread this, I have 2 options that I can think of:
>>>
>>> 1) Build the processing into classes that are NOT EOs, and copy the relevant information into these structures so that it's not necessary to lock an editing context.
>>>
>>> 2) Have multiple editing contexts, with all the heavyness that will come with thousands of EOs being duplicated.
>>>
>>>
>>> I really hate #1, since everything is working so nicely, and I really appreciate EOF doing all the heavy lifting of relating everything.
>>
>> Any reason why you can't copy the objects via their globalID into another thread and hand off the processing...
>
with regards,
--
Lachlan Deck
_______________________________________________
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