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
We have a few places in the Antidote codebase that make use of ETS tables (search for ets:). It is not easy to see at a glance what is stored in the tables and whether any processes use the same table as shared memory.
For example: clocksi_readitem_server:get_active_txns_key_internal passes a table-id to clocksi_vnode:get_active_txns_key and it is not directly clear who owns the table.
I suggest to refactor this such that we have a separate module for each table that has a name / can be used in multiple modules. The module should have a clear API such that it is clear what is stored in the table.
Instead of passing around table names (atoms) or table-ids we could then use different custom types for the different tables.
The text was updated successfully, but these errors were encountered:
We have a few places in the Antidote codebase that make use of ETS tables (search for
ets:
). It is not easy to see at a glance what is stored in the tables and whether any processes use the same table as shared memory.For example:
clocksi_readitem_server:get_active_txns_key_internal
passes a table-id toclocksi_vnode:get_active_txns_key
and it is not directly clear who owns the table.I suggest to refactor this such that we have a separate module for each table that has a name / can be used in multiple modules. The module should have a clear API such that it is clear what is stored in the table.
Instead of passing around table names (atoms) or table-ids we could then use different custom types for the different tables.
The text was updated successfully, but these errors were encountered: