J'ai une application de serveur faite à Erlang. Depuis que j'ai une table de la Mnésique
qui stockent des informations sur les photos. Dans l'esprit de "tout est un
processus "J'ai décidé d'envelopper cette table dans un module Gen_Server , de sorte que le
Cela fonctionne simplement bien, mais que le module Devrais-je simplement ne pas en faire un processus et n'envoiffât plutôt que la table
à travers les fonctions de ce module? En cas d'insecte dans ce module, que
provoquerait le crash du processus d'appel, que je pense pourrait être meilleur, car
cela n'affecterait qu'un seul client, par opposition à maintenant, quand cela causerait la
Toute entrée est grandement appréciée. Gen_Server Le module est le seul qui accède directement à la table. Interrogation
et ajouter des informations à ce tableau est effectué en envoyant des messages à ce processus.
(qui a un nom enregistré). L'idée est qu'il y aura plusieurs clients
processus interrogeant des informations de cette table.
gen_server n'a aucun état. Tout ce ça
Nécessite est stocké dans la table de la Mnésique. Donc, je me demande si un gen_server est peut-être
pas le meilleur modèle d'encapsulation de cette table?
GEN_SERVER TRAVAIL DE CLASHY, laissant tout le monde sans accès à la table (jusqu'à ce que
Le superviseur le redémarre).
3 Réponses :
Je suppose selon Razor d'Occam Il y a Encapsulation d'accès à la table dans un module gen_server d'exister , surtout car il y a absolument aucun état stocké. Ce processus pourrait être nécessaire dans des situations lorsque vous avez besoin d'un accès à la table (ou à toute autre ressource) pour être
Je ne suis pas sûr de comprendre pourquoi vous avez décidé d'encapsuler une table avec un processus. La Mnésique est conçue pour médier plusieurs accès simultanés aux tables, à la fois localement et distribués sur un cluster.
Création d'un module API qui effectue toutes les opérations d'accès à la table et les mises à jour des informations particulières est une bonne idée car les fonctions API transmettent votre intention mieux dans le code qui les appelle. Il sera plus lisible que de mettre les opérations de la Mnsia directement dans le code d'appel.
Un module API vous offre également la possibilité de passer de la Mnésique à un autre système de stockage ultérieurement si vous en avez besoin. En utilisant les transactions de MNSIA dans votre module API vous protège de certaines erreurs de programmation en tant que MNSIA, les opérations de roulement qui se bloque. Le module API sera toujours disponible pour les appelants et permettra à n'importe quel nombre d'appelants d'effectuer des opérations simultanément, tandis qu'une API de Gen_Server a un point d'échec, le processus, qui peut rendre l'API indisponible.
La seule chose qu'une API basée sur Gen_Server vous donne sur une API pure-fonctionnelle consiste à sérialiser l'accès à la table - qui est une exigence inhabituelle et à moins que vous n'ayez pas besoin de cela, ce sera un tueur de performance.
C'est peut-être une bonne idée de gérer une table de la MNSIA à l'aide du processus Gen_Server unique lorsque vous souhaitez utiliser un accès sale et éviter les transactions. Cette approche pourrait être plus rapide que TXS, mais comme il est généralement nécessaire de le comparer.