Blog Entry

(View Disclaimer)

From time to time, for performance reasons or architectural implementation reasons, you need to use a variable globally across multiple instances of server side scripts. The way to do that within BSM is to use "state" variables. State variables are available on any script that runs in context of the server such as an Automation (serverside) or a right-click operation (serverscript).

One common use case is when you have automations set up to log entries to a database or to open tickets directly to the database. Since it would not be a well performing script to open and close the database connection over and over again, one solution is to open the connection once and hold onto it within a state variable.

The other idea typically used in conjunction with that is to have the automation script do quick checks at the top of the script to determine if the particular alarm needs processed, if so, push it to a global queue, list, collection, etc. Next, you would have another script that is waking up from time to time to check the queue for work to do.

Below is a script fragment example...
if( !state.myList )
{
var myList= java.util.HashSet();
state.myList = myList
}

The idea is, have your script set up to start when the server starts up (IE: script.onStarted). It checks to see if the state variable exists, if not, it creates it. This could be a queue to hold alarm ID's, a sql connection, etc.

Within the serverscript right-click, you can easily add items to the list such as....

state.myList.add( "Junk" )

Another use case I remember from the past was a script that loaded a bunch of data from a database and then used this information for automation scripts, additional algorithm logic, etc.

As always, be careful, while state variables are useful, you need to be careful, the state variable is held in the engines core JVM, as in java heap, try not to load tons-o-data.

Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).

It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.