Interacting with a distributed store
Once prepared, a distributed store behaves much like other MemoryStore
Store objects as described in
Using the MemoryStore. However, be aware of the following differences:
The schema for tables in a distributed store is not allowed to expose DataViews.
A distributed store (as opposed to other, non-distributed stores) supports notifications. For more information, see
Notifications.
Exceptions. In an in-memory store, only the
Row.commit() action can throw exceptions. However, in a distributed store, most actions can throw exceptions. An exceptions represents runtime error that can be caught with a
try ... catch statement. This allows developers to choose what corrective action to take (such as logging, sending alerts, taking corrective steps, retrying later, or other actions). If no
try ... catch block is used with these actions and an exception is thrown, the monitor instance will be terminated, the
ondie() action will be called if one exists, and the monitor instance will lose all state and listeners. Exceptions can be thrown because of errors raised by third-party distributed cache providers. To discover what errors could be thrown because of third-party integration, you should refer to the documentation for the third-party provider in use. For more information on exceptions, see
Exception handling. The following are some of the actions that can throw exceptions:
Table.get() Table.begin() Iterator.step() Row.commit() Row.update() Notifications
Distributed store Table objects may support the subscribeRowChanged() and unsubscribe() actions. If subscribed to a table, RowChanged events will be sent to that context. Subscriptions are reference counted per context, so multiple subscriptions to the same table in the same context will only result in one RowChanged event being sent for every change. Monitors should unsubscribe when they terminate (for example, in the ondie() action) to avoid leaking subscriptions.
The store factory bean property
rowChangedOldValueRequired (see also
Standard configuration properties for distributed stores) indicates whether subscribers receive previous values in
RowChanged notification events for updated rows. When this property is set to
true and the
RowChanged.changeType field is set to
UPDATE the
RowChanged.oldFieldValues field is populated.
Notifications can impact performance, so are not recommended for tables in which a large number of changes are occurring. While TCStore and BigMemory Max support notifications, they do not support population of the old value in RowChanged.changeType = UPDATE events.
Within a cluster of correlators, if a table has subscriptions to RowChanged notifications, then all correlators must subscribe RowChanged notifications for that table, even if some correlators do not consume the events. This ensures all nodes receive all events correctly.
Support for notifications is optional, but if the driver does not support notifications, calls to Table.subscribeRowChanged() and Table.unsubscribe() will throw OperationNotSupportedException errors.
There is no support for RowChanged notifications for any extra fields (if supported). Only fields named in the schema are included in a RowChanged notification.
Some drivers do not provide RowChanged notifications for the rows removed by a Table.clear() operation. This behavior is driver-specific, therefore consult the driver documentation for more details.
Some drivers, such as TCStore, support sending a MissedRowChanges notification event in situations where an unknown number of RowChanged events may have been dropped, for example, due to a failure or high load.
Neither the TCStore driver nor the BigMemory Max driver set the old values with a RowChanged event. The old values sequence will always be empty for both of these drivers.
The BigMemory Max driver sets new values in the RowChanged event, but the TCStore driver does not. Therefore, if you need the new values in TCStore, you need to explicitly get them (using Table.get or similar).
See also the description of
com.apama.memorystore.RowChanged in the
API Reference for EPL (ApamaDoc) .