Best practice for ETS use

Hi guys,

Having a running prototype, I now try to challenge my choices and refactor my project.

I’m currently using several ETS tables that I keep track of in a Map used as index. This index is passed in the state data of my GenServer.

When I need to use one of this store, I get it from my index but I’ve also noticed that they could also directly be accessed by the atom value of the ETS table. Coming from C / C++ this looks like a global variable to me that’s why I’ve chosen the Map approach (remember ? globals are baaaad).

Anyway, maybe I tend to over complicate the problem, what design do you usually apply ?

Thanks !!


Globals are not bad in Actor systems. A global name lets you call out to that name to do stuff, behind it it could be a GenServer, or multi-plexing out to hundreds of nodes, you do not care. :slight_smile:

1 Like

Ok thanks, this is the confirmation of what I began to feel :wink:


You seem to use :named_tables, that’s why you can access them by their names. But you can drop that from the option list (the line where you create the ETS table). If you use a GenServer to keep track of the table IDs, you no longer need named tables. You can also define the table as :private. That way no other process than the owner can read from or write to that table. (Or use :protected, if others may be able to read it, but only the owner should be able to write to it.)

I personally like to have as few named tables and named processes as I can. But if code readability improves with node-global or cluster-global names, then I just use them.

1 Like

Hi @semmitmondo,

Actually, I used to embed the ets table in my states :slight_smile:
I’ve refactored that to use named table. To be fully honest, I m’not sure which of the solution is the most maintainable as table name is generated… Must be pretty close.

Concerning access right on the table, as I’m using the eternal module to ensure my tables would not disappear on the first crash, I kept the standard :public accessor.

I’m done with “local” tunning so I begin to investigate the distribution stage, I may need to refactor again, we ll see :slight_smile: