Contents
The EventFlow Editor's Annotations tab provides two features for the current EventFlow module:
| Annotations |
| Memory Model Settings |
There are two labeled checkboxes in the Annotations section of the Annotations tab.
- References to this module override Input Stream schemas
-
Mark this module as hygienic by clearing the check box for the References to this module control. This is the default state for newly created modules.
Mark this module as non-hygienic by selecting the check box:
See Hygienic Modules for more on hygienic versus non-hygienic modules.
See EventFlow Editor Read-Only Canvas for information on the context menu command that can open non-hygienic modules in a way that shows how their input stream schemas will be overridden at runtime.
- Constants and dynamic variables in this module will be visible to any module referenced inside it.
-
The default state of this checkbox is cleared. In this state, constants and dynamic variables defined on the Definitions and Dynamic Variables tabs have scope only for this module, and can override only parameters defined in this module.
Now, let's say module Outer.sbapp contains a module reference to Middle.sbapp, which in turn contains a module reference to Inner.sbapp. With this checkbox selected, you can define a constant in Outer.sbapp, then reference it in either Middle.sbapp or Inner.sbapp. The constant defined in Outer.sbapp can override parameters set in either Middle or Inner.
The controls in the Memory Model Settings section determine the default transactional memory settings for the current module and any submodules.
-
Storage method settings can be overridden by individual Query Tables, operators, or parallel region queues in this module and its child modules.
-
Transaction isolation settings apply only to the current module and its child modules, and cannot be overridden.
-
Data distribution policy settings represent a single policy for distributing data across an availability zone. You can use the default if its settings are adequate for your configuration. Otherwise, specify a policy as needed.
The Memory Model Settings are effective ONLY if the current module, or one of its child modules, contains a Query Table, operator, or parallel region that has been configured to use transactional memory.
- Storage Method
-
Modifications are only visible outside of the current transaction when it commits. Snapshots are taken from the last committed transaction (that is, it is not a dirty read) to ensure read consistency during a transaction. No transaction read locks are taken during the transaction allowing object modifications to occur while reading an object. Read consistency is provided by the snapshot data across all fields in an object. This is the default transaction isolation level.
- Transaction Isolation
-
Modifications are only visible outside of the current transaction when it commits. Transaction read locks are taken for the duration of the transaction to ensure read consistency. All writes are blocked while a transaction read lock is held.
You can determine if a Query Table uses transactional memory by looking in the Query Table's Properties view, Table Settings tab. Look for In transactional memory as the Type setting.
Operators that store state have a Storage method control on the General tab of their Properties views. See transactional memory for a list of the operators that have this control.
Most operators can be configured to run in a parallel region using the Concurrency tab of their Properties views. Parallel regions have automatic queues for both incoming and outgoing tuples. You can specify the storage method for these queues in the same tab.
The options for Storage method are:
- Inherit from the referencing module
-
Default. This passes the storage method decision up to the current module's parent module, if any. If the current module is the primary module for this EventFlow fragment, this selection falls back to heap.
- In heap
-
Specifies that all EventFlow objects are to be stored in the Java heap memory allocated by the JVM engine that runs this EventFlow fragment. Running from the JVM's heap was the only option for legacy StreamBase releases before release 10.
- In transactional memory
-
The StreamBase Runtime offers transactional memory as an option for storing the data for StreamBase Query Tables and for operators that preserve state.
The options for Transaction isolation are:
- Read committed snapshot
-
Modifications are only visible outside of the current transaction when it commits. Snapshots are taken from the last committed transaction (that is, it is not a dirty read) to ensure read consistency during a transaction. No transaction read locks are taken during the transaction allowing object modifications to occur while reading an object. Read consistency is provided by the snapshot data across all fields in an object.
- Serializable
-
Modifications are only visible outside of the current transaction when it commits. Transaction read locks are taken for the duration of the transaction to ensure read consistency. All writes are blocked while a transaction read lock is held. This is the default transaction isolation level.
Both object isolation levels, serializable and read committed — snapshot, provide consistent, or repeatable reads during a transaction on the same node. This means that the same object field read multiple times in a transaction returns the same value. Read consistency is not guaranteed across nodes. See State Conflicts for details on how data inconsistencies are handled.
Extents always use this transaction isolation level:
- Read Committed
-
Extent iterations and cardinality will return inconsistent results in the same transaction if other transactions create or delete objects in an extent.