Long-lived variables

It is sometimes desirable to store data for longer than the lifetime of a single message passing through a flow. One way to do this, is to store the data in a database. This is good for long-term persistence and transactionality, but access (particularly write access) is slow.

Alternatively, you can use appropriate "long-lived" ESQL data types to provide an in-memory cache of the data for a certain period of time. This makes access much faster than it would be from a database, though this is at the expense of shorter persistence and no transactionality.

Long-lifetime variables are created by using the SHARED keyword on the DECLARE statement.

The Message Routing sample demonstrates how to define shared variables using the DECLARE statement. The sample demonstrates how to store routing information in a database table and use shared variables to store the database table in memory in the message flow to improve performance.

Long-lived data types have an extended lifetime beyond that of a single message passing through a node. They are shared between threads and exist for the life of a message flow (strictly speaking the time between configuration changes to a message flow), as described in this table:

  Scope Life Shared
Short lifetime variables
Schema & Module Node Thread within node Not at all
Routine Local Node Thread within routine Not at all
Block Local Node Thread within block Not at all
Long lifetime variables
Node Shared Node Life of node All threads of flow
Flow Shared Flow Life of flow All threads of flow
Features of long-lived ESQL data types include:

A typical use of these data types might be in a flow in which data tables are 'read-only' as far as the flow is concerned. Although the table data is not actually static, the flow does not change it, and thousands of messages pass through the flow before there is any change to the table data.

An example is a table which contains a day's credit card transactions. The table is created each day and that day's messages will be run against it. Then the flow is stopped, the table updated and the next day's messages run. It is very likely that such flows would perform better if they cached the table data rather than read it from a database for each message.

Another use of these data types might be the accumulation and integration of data from multiple messages.

Related concepts
ESQL nodes and debugging
ESQL variables
User-defined properties in ESQL
Related reference
DECLARE statement
ESQL ROW data type