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 13:43:07 +1100
On 02/12/2009, at 1:09 PM, Ken Anderson 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...
> #2 is expensive - a single context for all this stuff takes up a few hundred megabytes already.
>
> One compromise is to have multiple editing contexts, but have a number of the larger reference objects and its relationships in a different context that gets centrally referenced and locked.
>
> So the big question is, am I missing anything? Is there a paradigm or pattern I should apply that I'm not considering?
>
> Thanks...
>
> Ken
> _______________________________________________
> 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
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