Module etsmgr_srv

.

Copyright © (C) 2019, Fred Youhanaie

Behaviours: gen_server.

Authors: Fred Youhanaie (fyrlang@anydata.co.uk).

Description

This is the main etsmgr server (gen_server). It can manage multiple ETS tables from multiple clients.

The server is expected to be supervised either by an instance of etsmgr_sup, or a client's own supervisor.

All client requests to this server are expected to come from functions in the etsmgr module.

The server maintains an internal map of the ETS tables that it has been asked to manage. Each entry in this map is identified by a unique key supplied by the client, and contains a further map of details of the ETS table.

As well as the tables map above, we also maintain a map of client pids, where we keep count of the number of tables each client has. The count is used to ensure we do not unlink a client process until we've received del_table for all of the client's tables.

New entries are added via the new_table or add_table requests.

Existing entries are removed via the del_table request.

If the owner process of a table terminates, the server will receive an EXIT message. On receiving the message the entries for all tables owned by that process will be flagged as having no client owner.

Function Index

add_table/3manage an existing ETS table.
del_table/2Remove a table from the list of managed tables, and unlink from the client_pid.
info/1Return the tables currently under management.
new_table/4Create and manage an ETS table.
start_link/1 Starts the server.

Function Details

add_table/3

add_table(Inst_name::atom(), Table_name::atom(), Table_id::ets:tid()) -> {ok, pid(), ets:tid()} | {error, term()}

manage an existing ETS table.

This functions is expected to be called from the etsmgr module.

This function is typically called when an application needs etsmgr to manage its ETS table(s), which already exist, either because the application prefers to create its own tables, or it has detected that the instance of etsmgr that was already managing the ETS tables has crashed and restarted, and this server is the replacement instance.

del_table/2

del_table(Inst_name::atom(), Table_name::atom()) -> {ok, pid()} | {error, term()}

Remove a table from the list of managed tables, and unlink from the client_pid.

We can only remove an entry if the request comes from the registered client, or from the owner of the table. If this condition is not met, {error, not_owner} is returned.

We will also remove a table entry if the ETS table no longer exists.

Since the client is expected to be the owner, it is responsible for deleting or removing etsmgr as the heir.

info/1

info(Inst_name::atom()) -> map()

Return the tables currently under management.

This is primarily for debugging and troubleshooting.

A map is returned where each entry has the client supplied Table_name as key, and a further map as the value. The inner map contains details of the corresponding ETS table being managed.

new_table/4

new_table(Inst_name::atom(), Table_name::atom(), ETS_name::atom(), ETS_opts::list()) -> {ok, pid(), ets:tid()} | {error, term()}

Create and manage an ETS table.

This functions is expected to be called from the etsmgr module.

If Table_name is not known to etsmgr, a new ETS table will be created, the calling process will be the owner of the table, with etsmgr the heir, and etsmgr will be linked to the client process.

If an entry for Table_name already exists, then either the client has restarted following a crash, or there is a name conflict with another application. In the case of a restart, etsmgr will behave as if this is a fresh start, but the table will not be created and no data will be lost. In the case of a name conflict, an error will be returned.

start_link/1

start_link(Inst_name::atom()) -> {ok, Pid::pid()} | {error, Error::{already_started, pid()}} | {error, Error::term()} | ignore

Starts the server


Generated by EDoc