You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, in order to subscribe to transaction status changes, we need to add a listener to the commit pipeline. Then every time a FSC node commits a transaction, this will also trigger all subscribers. However, for replicated nodes, only one of them will successfully commit the transaction, and all others will not be notified. Hence, all functionality that depends on these notifications will not be triggered. As a more generic solution, we can have notifiers for any type of table by extending the persistence interfaces with two methods:
// Subscribes to delete's, insert's and update's of column fields
Subscribe(callback func(operation string, values map[string]string)) error
// Unsubscribes the listener
Unsubscribe() error
Since we have multiple persistence implementations, these will have to be supported for the following:
Memory
Badger
Sqlite
Postgres
For the first 3 cases, the approach will be similar to the current approach, where after each commit operation we also call a notifier. This approach will work, because these implementations do not support replication anyway. For the Postgres case, we need to use the Postgres notifiers, so that also all other replicas receive the notification.
The text was updated successfully, but these errors were encountered:
Currently, in order to subscribe to transaction status changes, we need to add a listener to the commit pipeline. Then every time a FSC node commits a transaction, this will also trigger all subscribers. However, for replicated nodes, only one of them will successfully commit the transaction, and all others will not be notified. Hence, all functionality that depends on these notifications will not be triggered. As a more generic solution, we can have notifiers for any type of table by extending the persistence interfaces with two methods:
Since we have multiple persistence implementations, these will have to be supported for the following:
For the first 3 cases, the approach will be similar to the current approach, where after each commit operation we also call a notifier. This approach will work, because these implementations do not support replication anyway. For the Postgres case, we need to use the Postgres notifiers, so that also all other replicas receive the notification.
The text was updated successfully, but these errors were encountered: