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 (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/lachlan.deck%40gmail.com > > This email sent to lachlan.d...@gmail.com with regards, -- Lachlan Deck _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
