Mike, I am going to jump in here. There is not a threading issue with TCFs in the Witango 5 server. Thread safety of TCFs was a T2K feature.
The issues will be that you have written code that is not multi request safe. The servers resources are thread safe, but you can write an application that isn't multi request. This will not dead lock the server or put it in a race condition but will hang your requests up until QUERYTIMEOUT kicks in and kills the request and frees the request's thread in turn allowing another request to be taken from the request queue and allocated to that thread. As a rule of thumb, 1 request is 1 thread. The threads are pre emptive and scheduled by the OS. The Witango server just manages their priority levels across different resources. If you have written your app and all the request threads get tied up in your logic for QUERYTIMEOUT the server will appear to be deaf when in fact it is just executing the code as it was written. These are not Server issues, but more how you have written you application. You will need to look at your application and think about whether more than one request can modify the resources that you are allocating in your application (variables, objects, filesystem, etc). For instance you can not rely on the fact that a request running in one thread will not be swapped out of context when writing to a file across several write actions. A different request running in another thread may infact be able to write something to the same file between the other requests write actions. Another scenario would be if you instantiate a tcf in a shared scope (application, domain) and have another taf that purges that shared scope variable at the same time as another thread is accessing it. The object may be there for one method call and not the next. You have to code your application in a way where one taf cannot affect the critical resources of another taf. You have to think about how the resources will interact when accessed by multiple requests. Each request now runs in its own thread. TAF or TCF is irrelevant. Phil On 06/03/2004, at 4:26 AM, <[EMAIL PROTECTED]> wrote: >> >> Thank you for your reply. >> >> I need to better understand how TCFs & multithreading are handled by >> the new >> versions of the server (5, 5.5) to know for sure that all the code >> developed >> is still usable, after I install the Witango 5. >> >> In the example you provided I can understand the problem but I do not >> see >> the solution. I have checked all the new documents (for v. 5 on your >> website) and did a search for "thread"; I found about 20 hits; none of >> them >> dealing with programming. >> >> Where should I look in the documentation to find a clear explanation on >> handling multithreading? Is there such a document? >> >> Thank you. >> Mike Bravu >> >> -----Original Message----- >> From: Customer Support [mailto:[EMAIL PROTECTED] >> Sent: Thursday, March 04, 2004 22:36 >> To: [EMAIL PROTECTED] >> Subject: Re: Witango-Talk: Thread Safe Class file >> >> The thread safe property for a TCF in the dev studio is actually no >> longer >> relevant in the Witango 5 Server as each request runs in its own thread >> rather than being passed into different resource threads. This was >> only an >> issue in the cooperatively threaded T2K server and how it worked. The >> architecture of the new server does not use this property and there is >> no >> penalty in performance when using TCFs, except for the instantiation >> of the >> object. >> >> TCFs aside you do have to be careful with the preemptive threading in >> the >> Witango 5 Server with shared scopes variable (custom scope, application >> scope) as you can have one request change a variable that another >> thread may >> be using. Take for instance a while action using a custom scoped >> variable >> in one thread like this (pseudo code): >> >> myScope$MyVar=0 >> WHILE (myScope$MyVar != 100) { >> Other Actions >> Increment myScope$MyVar >> } >> >> If another thread is started and runs the same code there is a chance >> that >> both could increment myScope$MyVar simultaneously. Let say that the >> value >> of myScope$MyVar is 99 when this occurs, there is a chance that this >> loop >> will never exit as myScope$MyVar is equal to 101 before >> the end of the loop iteration. This would create an infinite loop. >> Request scope is the safest scope followed by user scope which would >> only >> have this type of issue in a framed site. >> >> I will let the doc writers know to update the manual and engineering >> so they >> can decide what to do with the dev studio. >> >> Witango Support >> >> On 05/03/2004, at 3:59 PM, <[EMAIL PROTECTED]> wrote: >> >>> >>> >>> I have noticed that for any TCF object, no matter how simple (even an >>> empty one), the property reads "Thread Safe: No". >>> >>> According to the documentation: >>> "If the field indicates No (not thread safe), Witango Server waits for >>> one execution of the instance to complete before it starts another, to >>> avoid any interference between the two. From the user's perspective, >>> the difference is in performance only. " >>> If this is true, what difference does it make if we have an algorithm >>> to handle critical sections? >>> >>> For all practical reasons, once one creates such an object there is a >>> performance penalty. >>> Perhaps the documentation should more clearly state this problem with >>> TCFs. >>> >>> The "thread safe" subject is so briefly mentioned in the manual is >>> difficult to understand why is it mentioned at all... >>> >>> Where do I go wrong? >>> >>> - Mike. >>> >>> >>> >>> >>> -----Original Message----- >>> From: Fogelson, Steve [mailto:[EMAIL PROTECTED] >>> Sent: Monday, March 01, 2004 12:05 >>> To: '[EMAIL PROTECTED]' >>> Subject: RE: Witango-Talk: Thread Safe Class file >>> >>> Actually, I read about "thread safe" when reviewing Witango >>> documentation for class files. Seemed like it would be advantageous >>> with multi threading version 5. Maybe it is no big deal not to be >>> thread safe. I just thought it would allow Witango to handle more >>> concurrent requests. >>> >>> I checked a couple of my class files (per documentation) to see if >>> they were thread safe and it indicates they are not. So I was >>> wondering: >>> >>> 1) Do we have the ability to change this flag or does the app studio >>> determine if it is? >>> 2) What is required of a class file in order to be thread safe >>> >>> Thanks for the comments >>> >>> Steve >>> >>> -----Original Message----- >>> From: Robert Shubert [mailto:[EMAIL PROTECTED] >>> Sent: Monday, March 01, 2004 1:28 PM >>> To: [EMAIL PROTECTED] >>> Subject: RE: Witango-Talk: Thread Safe Class file >>> >>> >>> Oops, my bad ... I was replying to Bill's post, who replied to you, >>> replying to Bill who replied to Steve ... I think. :) >>> >>> -----Original Message----- >>> From: Alan Wolfe [mailto:[EMAIL PROTECTED] >>> Sent: Monday, March 01, 2004 1:36 PM >>> To: [EMAIL PROTECTED] >>> Subject: Re: Witango-Talk: Thread Safe Class file >>> >>> Steve was asking actualy so i dont know what his intentions are, i was >>> just tossing in my 2 cents (: >>> >>> ----- Original Message ----- >>> From: "Robert Shubert" <[EMAIL PROTECTED]> >>> To: <[EMAIL PROTECTED]> >>> Sent: Monday, March 01, 2004 10:25 AM >>> Subject: RE: Witango-Talk: Thread Safe Class file >>> >>> >>>> Alan, >>>> >>>> If you mean to make a TCF that is thread safe, it depends on why you >>>> need it thread safe. Normally just using the method scope for all >>> action >>>> internal to the TCF is enough, however if you need to deal with >>> external >>>> dependencies, ie writing to two different log files in tandem, then >>> you >>>> need to use a higher scope, such as instance, or domain to record >>>> your busy flag. Since I have more than one server, I can only depend >>>> on my database as a single point of reference, and therefore set and >>>> release >>> a >>>> flag in my database to solve certain overrun problems. Make sure to >>>> alert yourself or log when contention occurs since it can become a >>>> problem can cause congestion if it goes wrong. >>>> >>>> Robert >>>> >>>> -----Original Message----- >>>> From: Alan Wolfe [mailto:[EMAIL PROTECTED] >>>> Sent: Monday, March 01, 2004 12:42 PM >>>> To: [EMAIL PROTECTED] >>>> Subject: Re: Witango-Talk: Thread Safe Class file >>>> >>>> hey Bill, correct me if im wrong but wouldnt this work too? I just >>> like >>>> this method because it waits until the other thread is done, so you >>> dont >>>> have to have code to recheck if it's busy. >>>> >>>> while (user$active != 0) >>>> { >>>> (doing nothing...) >>>> } >>>> >>>> user$active = 1; >>>> >>>> do the stuff >>>> >>>> user$active = 0; >>>> >>>> ----- Original Message ----- >>>> From: "Bill Conlon" <[EMAIL PROTECTED]> >>>> To: "Witango-Talk" <[EMAIL PROTECTED]> >>>> Sent: Monday, March 01, 2004 9:11 AM >>>> Subject: Re: Witango-Talk: Thread Safe Class file >>>> >>>> >>>>> Here's pseudo code to handle critical sections: >>>>> >>>>> if (user$active>0) >>>>> error return, "sorry, you have a request pending, try again" >>>>> else >>>>> user$active=user$active+1 >>>>> if (user$active=1) >>>>> process stuff >>>>> else >>>>> error return: "sorry a thread inserted itself between the >>> first >>>>> error check and the processing check" >>>>> endif >>>>> user$active=user$active-1 >>>>> good return >>>>> >>>>> >>>>> >>>>>> Where would I look to find out how to create a "thread safe" class >>>> file? >>>>>> >>>>>> Steve Fogelson >>>>>> Internet Commerce Solutions >>>>> >>>> >>>> _____________________________________________________________________ >>>> _ >>>> _ >>>> _ >>>>>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >>>>>> >>>>> >>>>> >>>>> Bill Conlon >>>>> >>>>> To the Point >>>>> 345 California Avenue Suite 2 >>>>> Palo Alto, CA 94306 >>>>> >>>>> office: 650.327.2175 >>>>> fax: 650.329.8335 >>>>> mobile: 650.906.9929 >>>>> e-mail: mailto:[EMAIL PROTECTED] >>>>> web: http://www.tothept.com >>>>> >>>>> >>>>> >>>> >>> ______________________________________________________________________ >>> _ >>> _ >>>>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >>>> >>>> >>> ______________________________________________________________________ >>> _ >>> _ >>>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >>>> >>>> >>> ______________________________________________________________________ >>> _ >>> _ >>>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >>> >>> ______________________________________________________________________ >>> _ >>> _ >>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >>> >>> ______________________________________________________________________ >>> _ >>> _ >>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >>> ______________________________________________________________________ >>> _ >>> _ >>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >>> >>> ______________________________________________________________________ >>> _ >>> _ >>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >> >> _______________________________________________________________________ >> _ >> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >> >> _______________________________________________________________________ >> _ >> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
