EOF / multithreading app design question
EOF / multithreading app design question
- Subject: EOF / multithreading app design question
- From: Ken Anderson <email@hidden>
- Date: Tue, 1 Dec 2009 21:09:58 -0500
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.
#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