Re: EOF / multithreading app design question
Re: EOF / multithreading app design question
- Subject: Re: EOF / multithreading app design question
- From: Ken Anderson <email@hidden>
- Date: Tue, 1 Dec 2009 23:26:58 -0500
I could certainly copy them, but that would require another EC, my
option #2...
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... 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...
_______________________________________________
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