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 (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
