• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: EOF / multithreading app design question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
  • Follow-Ups:
    • Re: EOF / multithreading app design question
      • From: Lachlan Deck <email@hidden>
References: 
 >EOF / multithreading app design question (From: Ken Anderson <email@hidden>)
 >Re: EOF / multithreading app design question (From: Lachlan Deck <email@hidden>)

  • Prev by Date: Re: EOF and multi-threading
  • Next by Date: Re: EOF / multithreading app design question
  • Previous by thread: Re: EOF / multithreading app design question
  • Next by thread: Re: EOF / multithreading app design question
  • Index(es):
    • Date
    • Thread