Siebel Tools >  Assigning Null to Variables in Siebel eScript

Assigning Null to Variables in Siebel eScript

Questions about assigning null to variables within eScript code.

1) Within eScript, Siebel recommends explicitely releasing the memory used by Siebel objects by setting the variables to null within a finally block. Besides Siebel objects, are there any other types of objects that should be set to null? For example, what about objects created with the new statement?
     var myArray = new Array();
     var myDate = new Date();
     // any other object types?

2) In order for a variable to be referenced inside of a finally block, is it required for the variable to be declared before the try block, or can it be declared within the try block without any risk of not having all of the null statements work properly.

     try
     {
          // The variables are declared inside the try block
          var myBusObj = TheApplication().GetBusObject("foo");
          if (...)
          {
               var myOtherBusObj = TheApplication().GetBusObject("bar");
          }
     }
     catch (e)
     {
          ...
     }
     finally
     {
          // Is there any possibility that these statements won't work because
          // the variables might not be in scope for this block?
          myBusObj = null;
          myOtherBusObj = null;
     }

3) If the return value from the property set GetChild() method is set to a variable, should this variable also be set to null? Or is only setting the parent property set variable to null sufficient to release all memory.

4) Before setting a variable to null that references a property set, is it necessary to call the Reset() method to clear the property set, or is simply setting the variable to null sufficient to release all memory?

5) Would the following statement cause a memory problem because the business object is not set to a variable and therefore not set to null?

SOLUTION

Process memory is divided in two different spaces; the stack, which is allocated/deallocated automatically according to function invocation and the heap, which is a kind of global memory area that do not follow function stack and needs memory management.

Variables local to functions belong to the stack part, hence they are automatically removed when the function ends. Only native type variables may be stored in the stack, this helps in estimating the size of memory necessary for loading a function. When a composite object (Bookshelf: Siebel eScript Language Overview > Data Types in Siebel eScript > Composite Data Types in Siebel eScript) is used in a function, only the reference (pointer) is allocated in the stack. This is the reason why a new statement is necessary for creating an instance of an object. The new operator will create the corresponding object in the heap storage space and increase a reference counter in order to manage number of existing references on this object.

The aim of assigning null to references is to decrease this reference counter; when the counter is equal to zero, it means the object is no longer referenced hence eligible for being removed by the garbage collector.

Here are answers to asked questions:
1) Within eScript, Siebel recommends explicitly releasing the memory used by Siebel objects by setting the variables to null within a finally block.

Besides Siebel objects, are there any other types of objects that should be set to null? For example, what about objects created with the new statement?

The answer to this is found in the "Destroy Object Variables When No Longer Needed" section of the "Siebel Scripting Best Practices (Doc ID 477766.1)" document, where the following is stated:

Memory leaks are a common problem, so when a script creates an object reference, that same script must destroy the object reference before leaving the method.

Object references are:
• COM objects
• Property Sets
• Business Services
• Business Components
• Business Objects
• Applets

These are the only objects that need to be destroyed in Siebel eScript.



2) In order for a variable to be referenced inside of a finally block, is it required for the variable to be declared before the try block, or can it be declared within the try block without any risk of not having all of the null statements work properly? 

 Escript is not like other languages. You can declare a variable in one block and access it in another block. For more information please refer Doc Id 807679.1 and 1051274.1 on Oracle support.

3) If the return value from the property set GetChild() method is set to a variable, should this variable also be set to null? Or is only setting the parent property set variable to null sufficient to release all memory.

PropSet.GetChild method returns a new reference to the designated object, so when assigning a variable with this method automatically increases the reference counter. Hence it is necessary to set this variable to null for performing the reverse task (diminish the reference counter), otherwise the reference counter will not be decreased to zero.

4) Before setting a variable to null that references a property set, is it necessary to call the Reset() method to clear the property set, or is simply setting the variable to null sufficient to release all memory?
PropSet.Reset method is designed for resetting content of the PropertySet object. Its aim is to release every underlying resource in order to re-use it in a different context. This helps avoiding setting the object to zero for de-allocating and than re-instantiating it, which would be very heavy in terms of memory and cpu consumption.

As explained previously, the destructor will handle the underlying resources release, so it is not necessary to invoke the PropSet.Reset method?

5) Would the following statement cause a memory problem because the business object is not set to a variable and therefore not set to null?
     var myBusComp = TheApplication().GetBusObject("foo").GetBusComp("bar");
     myBusComp = null;

In theory, the reference returned by the Application.GetBusObject is temporary defined and no longer used, so it is supposed to be automatically reset. Because confusion may happen between implicit and explicitly declared variables, it is advised to not rely on this functionality and systematically declare every variable used in order to have the way to clearly release them at the end of the function.
Please, note that other information about the garbage collector is available in the posting number 38-3173780291 on SupportWeb.

Additional information:
Limiting scope of variables is a simple way for increasing memory usage, hence performances. That said, declaring a variable in the try section and using it in catch/finally sections is a common mistake done by developers, thinking that if these three sections are designed for working together, scopes are mixed.

The reality is less ideal than that; since the variable is declared in the try block, its scope is not valid in any other block at the same or an upper level, including catch and finally.

This is the same thing in other languages; C++, C#, Java, JavaScript and so forth. The only difference is that since eScript and JavaScript languages are ECMAScript compliant; this standard allows dynamic declaration on the fly. This feature offers choosing the type of the variable and changing it during the code execution. The counterpart is that compiler and the interpreter are quite lax concerning variable definition. For example, it offers omitting the var operator and assigning a new variable for declaring it. In such a context, nothing ensures that a variable using the same name of another declared in a different block will refer to the same final object. This lack of rigorousness may introduce coding mistakes.
In consequence, it is not safe to rely on this feature.