Contents
The EventFlow Editor's Annotations tab provides two features for the current EventFlow module:
| Annotations |
| Memory Model Settings |
There are two labeled check boxes 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:
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 check box is cleared. In this state, constants and dynamic variables defined on the Definitions tab 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 check box 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 Memory Model Settings apply to the current module and are effective ONLY if the current module, or one of its child modules, contains a Query Table that has been set to use transactional memory. Check this by looking in the Query Table's Properties view, Table Settings tab. Look for In transactional memory as the Type setting.
In this case, the Query Table's data is stored in transactional memory. The Memory Model setting determines the transaction isolation level for writes to such Query Tables. The options 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. This is the default transaction isolation level.
- 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 setting passes on to sub-modules. That is, if you make a non-default setting in Outer.sbapp, which calls Inner.sbapp, the transactional memory Query Table in Inner.sbapp is affected.