Apple

2012/2/17 Kieran Kelleher <email@hidden>

On Feb 16, 2012, at 8:58 AM, Paul Dunkler wrote:

Hi Alexis,

Hi,

You should carefully read the source of BackgroundTasks and watch Kieran's presentation.

thanks for that tipp. I'll do that!

You should directly lock ec's not the osc. If you got deadlocks, that maybe causes by ec's or eo's shared between threads, you should instead pass globalIds and retrieve the eo in each thread with ec.faultForGlobalId.

I'm not sharing any EO's between threads.

Then if you have massive eof processing going on in parallel, you should use a OSC pool.

Also a good suggestion. You mean the ERXObjectStoreCoordinatorPool, right?

He said "a OSC pool", meaning ERXTaskObjectStoreCoordinatorPool probably. ERXObjectStoreCoordinatorPool is "the OSC pool" :-)

ERXTaskObjectStoreCoordinatorPool is used by ERXAbstractTask, which is explained and demo'd in the BackgroundTasks example.

Thanks Kieran, that's what I meant :)
I was on a eclipse free laptop with my 64K connection crossing the pacific and couldn't remember the wonderized name :)

Alex

Good luck

Alex

2012/2/16 Paul Dunkler <email@hidden>

Hi Community,

i'm currently working on a WebObjects-Application which uses the Quartz Scheduler to schedule and run thousand but thousand of jobs. Every job is doing some work in the database (Like reading, computing and then Updating/Deleting some Details from the database).

This works quite well when i only allow Quartz to start one Single Thread for Job Execution. But when i configure more than one thread, it seams that i have problems with EditingContext / ObjectStoreCoordinator-Locking or something else.

The Question is: What should i do to achieve an entirely independent EOF-Stack per Quartz Thread? If it is possible without ramping up a complete EOF-Stack per Thread, this would be even better ;)

Currently i just tried to Create a new EditingContext per Job at the start, lock the rootObjectStore, do some things and then unlock the rootObjectStore and dispose the editingContext. But that doesn't seem to work for me.

// Job Start

EOEditingContext anEditingContext = ERXEC.newEditingContext();

anEditingContext.rootObjectStore().lock();

// Job Execution

// Job End

anEditingContext.saveChanges();

anEditingContext.rootObjectStore().unlock();

It would be nice to get your suggestions about this Topic.

--
Mit freundlichen Grüßen

Paul Dunkler

_______________________________________________
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

--
Mit freundlichen Grüßen

Paul Dunkler

<xyrality_logo_medium.png>

-----------------------------------------------------
XYRALITY GmbH • Lerchenstraße 28a • 22767 Hamburg
Paul Dunkler • Softwareentwickler
Mail: email@hidden
Tel: +49 (0) 40 23 51 78 97
Mobil: +49 (0) 151 252 228 42
Fax: +49 (0) 40 23 51 78 98
Web: http://www.xyrality.com/
Registergericht: Hamburg HRB 115332
Geschäftsführer: Sven Ossenbrüggen & Alexander Spohr
-----------------------------------------------------

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)

This email sent to email@hidden

References:
	>Entirely independent EOF on Quartz Threads - How to do? (From: Paul Dunkler <email@hidden>)
	>Re: Entirely independent EOF on Quartz Threads - How to do? (From: Alexis Tual <email@hidden>)
	>Re: Entirely independent EOF on Quartz Threads - How to do? (From: Kieran Kelleher <email@hidden>)