I know this is mostly directed at Robert, but I would like to take a stab at it.
TCFs are Thread Safe that means in simple terms that each instance of the TCF has its own set of method vars. To me it is bad form to create a TCF that affects variables of any other scope than method. In Essence it should be treated as a function 1. You pass it parameter 2. You Process the function using method scope vars (do not affect calling tafs vars in this process) 3. You pass the value back to the calling taf Yes you can affect calling var tafs but you are going to handle the thread safe issues yourself IMHO Ben Johansen -----Original Message----- From: Bill Conlon [mailto:[EMAIL PROTECTED] Sent: Friday, December 10, 2004 12:08 AM To: [EMAIL PROTECTED] Subject: Re: Witango-Talk: Objects versus branch Thanks everyone for your insights. Can I just ask for clarification on one thing -- object instantiation in a shared scope. Robert, it sounds like you run TCFs in a shared scope (such as application or domain) so the Object is created only once. For example, an init.taf might set up the class files for a domain: <@ASSIGN NAME="myObject" SCOPE="domain" VALUE="<@CREATEOBJECT TYPE='tcf' OBJECTID='MyObject.tcf'>"> Then within various appfiles you will invoke the methods: <@CALLMETHOD OBJECT=@@domain$myObject METHOD='foo(1,"test")'> So there is a single object instance, but the method can be called any number of times by this and other appfiles. Is my understanding correct? If it's correct, then how do you handle re-entrancy issues, method scope? thx. On Thursday, December 9, 2004, at 04:38 PM, Customer Support wrote: > The only thing that should be added is that unscoped variables can be > a performance hit. > > When an unscope variable is referenced the server starts looking for > the variable in the different variable stores ([Method then Instance > then] Request then User then Application then Domain then System). > Custom scopes fall outside of the Witango scope hierarchy; therefore, > only explicitly specifying the scope when returning the variable > allows Witango Server to find the variable. Cookie scope is also not > searched when no scope is present, though it does sit at the same > level in the scope hierarchy as user scope. > > We recommend that you always scope variables for optimum performance. > If you must use variables without scopes do not put them in large > loops (@FOR, @ROW, @WHILE, FOR Action WHILE Action). You will see a > performance difference when compared to scoped variables in loops > proportional to the number of iterations of the loop and the size of > the variable store in each scope. > > Witango Support > > On 10/12/2004, at 10:53 AM, Robert Shubert wrote: > >> >> >> 1. Scope. Can Objects be instantiated just once (say in application >> or domain scope) and used safely? It looks to me like you really >> should instantiate everything in request scope to avoid getting >> clobbered by another thread. >> >> I love objects and scope... I always name my object variables a little >> unique, and call them without a scope. This allows me to create an >> object in various scopes for various reasons: request or user when I'm >> developing, domain or custom when I'm in production. You can also >> beta-test on your production environment by leaving your production >> tcf >> in domain/application/custom and loading your beta tcf into >> request/user. Witango 5.0+ is a pro at managing TCFs in all scopes, >> and >> higher level scopes can really make them fast/easy to use, providing >> ever present functions akin to a custom tag. Just watch out how/when >> you >> purge/rebuild the higher scopes, you can pull a TCF out from under a >> running request. >> >> 2. Memory. Is each instantiated object a copy of the class file? It >> seems like application memory use would then be proportional to >> requests, whereas with branch/return application memory use is fixed >> (assuming cached) and data memory is proportional to the number of >> session. >> >> This is true, an application/domain level tcf would use about the same >> memory as a branched taf, and user scope would compound in the user >> var >> space for each user. >> >> 3. Performance. Does anyone have an idea of the extra burden placed >> on the server to manage object instantiation (for example, if TCF must >> be copied with each <@CREATEOBJECT>) >> >> It is very minor. There's effort with both of your methods, and both >> are >> very minor. I was once told that the way Witango handles TCFs (only, >> not >> other objects) is so close to a normal TAF that the decision on >> whether >> to use them or not should be made solely on the principles of >> programming. A more object orientated program design is good in many >> ways. HOWEVER, the use of TCFs is not truly objective, so beware of >> the >> pitfalls. >> >> Thanks. >> >> bill >> >> ______________________________________________________________________ >> __ >> 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
