Re: OSC's in background intensive-EOF threads
Re: OSC's in background intensive-EOF threads
- Subject: Re: OSC's in background intensive-EOF threads
- From: Miguel Arroz <email@hidden>
- Date: Thu, 4 Dec 2008 15:57:53 +0000
Hi!
I usually use separate applications for that. There was a thread
about this not so long ago. Essentially, App creates a request object
and stores it in the DB. BackgroundApp checks the DB every, say, 5
seconds, and if there's a request waiting, it will be processed.
Advantages:
1) You don't have to worry about OSCs, locking, performance
problems, etc on the main app;
2) You can offload the background app to a different server;
3) You can load-balance background tasks using several
BackgroundApp instances (in different CPUs/Cores/Servers) and control
who does what based on the request semantics.
4) You can start and stop background apps (if you want to upgrade
them, or ir you want to run then only at night or so) without
disrupting the main application.
Yours
Miguel Arroz
On 2008/12/04, at 15:42, Kieran Kelleher wrote:
For intensive EOF background processes, I use a separate OSC. I am
curious as to what resource strategy some of you use ........ do you:
1) Create a new OSC for the life of the long running EOF intensive
task,
2) Maintain a pool or 1 or more OSC's to share among background tasks,
3) Use a Wonder OSC pool for the whole app and not think about
special handling of OSC's in background tasks,
4) ..... other ......?
Note I am only talking about intensive EOF processes here where we
are processing thousands or 100's of thousands of EO's. Typically I
use strategy 1 or 2. Anyone like to share viewpoints on their
preferred strategy?
-Kieran
_______________________________________________
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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