Well, as with all other programming stuff, the better design depends on your situation.
I agree using and locking the same edting context for request and background tasks will lock up you app server (multithreaded or not). But maybe you don't need to lock during the entire background task. If your task just fetches a few properties from some eo's and then spend al it's time communicating with a webservice or similar, the task should only lock the ec during retriaval of those properties, the time spent there will not be noticeable in the app. On the other hand; if you are running a expensive computation requesting constant access to eo's it will properly be a bad idea to use the same edting context for request and backend tasks, since it will lock you app server while a new request using the ec is waiting for the backend task to finish. The reason consider using the same editing context, is that sooner or later i properly wan't my eo's to be displayed to the user and usign two ec's will either force me to localize eo's (and using global ids), which i consider a bit clumsy, or i will have to keep a reference to the newly created ec in the background job, and that bookkeeping adds up, if the user can perform several backend jobs. Cheers Tonny On Mon, May 26, 2008 at 5:32 AM, Guido Neitzer <[EMAIL PROTECTED]> wrote: > On 24.05.2008, at 15:09, Tonny Staunsbrink wrote: > > Also bear in mind that accessing the session's editing context within the >> performAction thread is a sure path to deadlocks. >> Using the sessions editingContext in a background thread with proper >> locking/unlocking should be ok I think. >> > > Not really. If that thread takes a while and you lock the editing context > in the beginning, you'll get a locked application as soon as the session is > checked out again and tries to lock it's editing context. > > cug > > -- > http://www.event-s.net > >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
