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. > >> Good luck >> >> Alex >> >> 2012/2/16 Paul Dunkler <[email protected]> >> 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 protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/alexis.tual%40gmail.com >> >> This email sent to [email protected] >> >> > > -- > Mit freundlichen Grüßen > > Paul Dunkler > > > > <xyrality_logo_medium.png> > > ----------------------------------------------------- > XYRALITY GmbH • Lerchenstraße 28a • 22767 Hamburg > Paul Dunkler • Softwareentwickler > Mail: [email protected] > 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 protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/kelleherk%40gmail.com > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
