Re: WOLongResponesePage Problem
Re: WOLongResponesePage Problem
- Subject: Re: WOLongResponesePage Problem
- From: "Tonny Staunsbrink" <email@hidden>
- Date: Tue, 27 May 2008 22:58:22 +0200
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@hidden> 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.
cug
--
http://www.event-s.net
_______________________________________________
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