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, below.
Exceptions – In an in-memory store, only the
Row.commit() action can throw exceptions. However, in a distributed store, most actions can throw exceptions. Exceptions represent a 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
Catching exceptions. The following are some of the actions that can throw exceptions:
Table.get()Table.begin() Iterator.next() 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 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 BigMemory Max supports notifications, it does 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.