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
