roeland
Hi,
I have a huge map which I store in a GenServer to quickly handle calls. Another process is responsible for creating this map and then sends it to the GenServer. However, as this table is very large, it blocks the GenServer from responding to other requests while the map is loaded into memory. I am not sure what would be the best approach to sending the map to the GenServer, while handling requests and I cannot find the right keywords to find the solution.
One possible solution I came up with is instead of updating the state of the GenServer to start a new GenServer process with the map, wait until it is ready and then direct requests to this process and stop the previous GenServer process. Using a Registry this is probably not very difficult, but I expect that I am not the first to run into this problem and that there are off-the-shelf solutions that I just cannot find.
I would love a recommendation on how to approach this problem. Thanks!
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Elixir, Erlang & messaging conferences from Code Sync. Next up: ElixirConf US (10–11 Sep) & Code BEAM Europe (21–22 Oct), Haarlem + online.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 6 to 1- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
rvirding
The only thing to be aware of with ETS is that the interface has basically no transactions so if you are going to allow multiple processes to update the tables you can get into a mess if you are not careful. The solution is generally to have one server which does all the upgrading.
rvirding
Persistent term can be very costly if you do updates or deletes. Worst case it can cause a GC of the whole system.
roeland
It does get updated depending on the usage hourly to weekly, from persistent_term — OTP 29.0.2 (erts 17.0.2) it seems that the update is costly. Might still be a possibility
. Thanks.
roeland
That sounds brilliant. We previously used
:ets, but then it was overkill. I reread https://elixir-lang.org/getting-started/mix-otp/ets.html and it describes something very close to what I want to dompope
If the map is never updated and never needs to be cleaned up then a :persistent_term could work, too.
benwilson512
This seems like a perfect case for
:ets.:etstables are another kind of key value structure that you can actually edit and query from concurrently. They also don’t need to be garbage collected.