Apama 10.15.5 | Developing Apama Applications | Developing Apama Applications in EPL | Using EPL Plug-ins | Using the distributed MemoryStore | Interacting with a distributed store
 
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()
*Performance differences. See Overview of the distributed MemoryStore for the advantages and disadvantages of using a distributed store as compared to an in-memory store.
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) .