The architecture of shared memory appears to limit sharing to processes on the same machine. How does TIBCO StreamBase® allow sharing across the network?

Architecture and considerations

Within the StreamBase Runtime services, "shared memory" is implemented as Managed Objects in Transactional Memory. Transactional Memory is implemented as System V Shared Memory Segments on some platforms and as file-system-based store on others. 

Unlike using shared memory segments directly, Transactional Memory is not shared between processes running on the same machine. This permits the Runtime to have collections of objects that are spread across multiple machines. This is called Distributed Transactional Memory (DTM). 

Managed Objects are replicated between nodes, so collections of Managed Objects:

• may be partitioned so that parts of the collections reside on separate nodes,
• are possibly replicated, maybe multiple times, to support seamless high-availability and dynamic scaling. 

See the StreamBase Architects' Guide:
  http://devzone.tibco.com/sites/streambase/latest/sb/sb-product/documentation/architectsguide/index.html
for conceptual models and detailed descriptions. 

Although the StreamBase Architects' Guide describes the facilities from the perspective of Java language programming, The StreamBase EventFlow language simplifies development considerations within the visual programming model.

The StreamBase EventFlow constructs that may be configured to use transactional memory are those that preserve some state, like Query Tables, Join, Merge, Pattern, Dynamic Variables, Sequence, Aggregate, the Java Operator base class (for custom operators and adapters), JDBC buffers, and parallel-region queues (concurrency settings). Note that older releases may only support a subset of operators that support transactional memory.

A very common and efficient pattern is to only share in transactional memory computation results, typically stored in a Query Table. In this way only one node does the computation work for any given input, but all results are available from the shared Query Table to all nodes for reference and further work.

The minimal configuration for sharing Query Table state between nodes in a cluster is:

1. Start with the simplified "Implicit binding example" (primaryMemberPattern implied default) from Help topic:
  TIBCO StreamBase Documentation > Configuration Guide > Runtime Configuration Types > Runtime Node Configuration
and name it (for example) "mydeploy.conf"

2. Modify by adding a second node:

name = "HAConfig"
version = "1.0"
type = "com.tibco.ep.dtm.configuration.node"
configuration = {
  NodeDeploy = {
    nodes = {
      "A1.nodedeploy" = {
      }
      "A2.nodedeploy" = {
      }
    }
    availabilityZones = {
      dynamiczone = {
        dataDistributionPolicy = "dynamic"
        // matches dynamicPartitionBinding .* by default
        }
    }
  }
}

3. In the application, which will be run multiple times in different nodes, set the Query Table "Type" to "in transactional memory".

This must be run outside of SB Studio in order to reference the node deployment configuration from the 'epadmin' commands:
1. Node 1
  epadmin install node nodename=A1.nodedeploy application=app.zip nodedeploy=mydeploy.conf
  epadmin servicename=A1.nodedeploy start node
2. Node 2
  epadmin install node nodename=A2.nodedeploy application=app.zip nodedeploy=mydeploy.conf
  epadmin servicename=A2.nodedeploy start node

By default, shared state is only and automatically shared by the same elements in the same application started in two or more nodes in a cluster. An application counts as the "same" if it is the same top-level application running in the same StreamBase engine container. To replicate data to a different application write the data to a message bus and have the other application retrieve it from the bus.