Execution Environment

The Oracle Data Relationship Management engine is a multithreaded, multimachine environment and scripts may execute simultaneously on multiple threads and across machines. While you can create values and store them in the global scope, you should not rely on this behavior because when your script executes on another thread that global value will not be present. Similarly, global values are not updated across Data Relationship Management engine instances or machines. In addition, becauseData Relationship Management supports multiple live versions, if you rely on calculating a value for a node and storing that value in the global scope, you may produce incorrect values if a different script accesses the property for another node.

Note:

For the same reason that you should not store variables in the global scope, you should also avoid modifying the built-in Data Relationship Management object prototypes, because you cannot be sure that your modifications have been made across all engine instances and threads.

Setting Script Timeouts

To prevent excessive engine locks, scripts that take too long to execute without returning a value are terminated based on a time-out setting. The script time-out can be set for each property definition and validation.

The time-out is per execution context, so if an export is exporting the script property of 100 nodes and the time-out for the property is set to 30 seconds, then the export may take up to 50 minutes, because each node can take 30 seconds to evaluate its property. However if a script property calls another script property, then it does not increase the time-out. For example, if PropA has a 10 second time-out, PropB has a 20 second time-out, and PropA calls PropB which then starts a long-running calculation, when 10 seconds have elapsed, the evaluation of PropA is terminated because its original time-out was exceeded.

Preventing Infinite Loops

A script that results in an infinite loop (also known as a stack overflow) is a serious error which can cause a server process to terminate unexpectedly. Although Data Relationship Management attempts to prevent such scripts from executing, you should exercise caution when writing self-referencing, or recursive, scripts. Always test new scripts in a development environment before deploying to production.

A simplified example of a script that will loop infinitely is shown below. Because the script includes a call to itself, but never terminates execution, the engine executing the function will eventually terminate due to lack of resources. Lastly, because the script never calls the Data Relationship Management engine, there is no chance to catch the overflow and stop the script.

function badFunc(a) { badFunc(a); }

badFunc("oops");

Performance Considerations

For the best performance, avoid referencing formula-derived properties from a script, and vice versa. Scripts in general offer the best opportunity for performance tuning optimization, compared to formulas, due to considerations such as just-in-time (JIT) compilation for native hardware, including 64-bit processors. Scripts are also tuned by the JIT compiler for actual execution characteristics and will run faster over time.