L'un des avantages des modèles de traitement des messages comme les acteurs et les agents est que les problèmes de concurrence traditionnels (principalement la synchronisation de l'état partagé) ne sont plus un problème. L'acteur peut garder l'état privé et le mettre à jour librement sans verrou. Le framework d'acteur garantit qu'un seul message est traité à la fois. Avec le traitement sérialisé, le code peut être écrit sans verrouillage.
Dans votre exemple d'utilisateurs enregistrant un formulaire, en supposant que l'acteur conservait une liste de certaines données de chaque formulaire, l'acteur peut mettre à jour la liste sans verrou, car le cadre garantit qu'un seul formulaire sera traité à la fois. Traditionnellement, vous devez verrouiller les accès à la liste ou utiliser une liste simultanée.
La stratégie de concurrence est un sujet légèrement différent et reste votre responsabilité (aucune stratégie n'étant la stratégie la plus courante). Pour changer légèrement votre exemple, disons que les deux utilisateurs essaient de mettre à jour l'instance de formulaire SAME en même temps. Sans stratégie de simultanéité, les changements de l'un remplaceront l'autre (probablement le dernier gagne). C'est bien, mais au mieux, cela entraîne un comportement inattendu pour l'utilisateur dont les modifications ont été écrasées. S'ils voient le formulaire qu'ils viennent de changer, il aura des valeurs inattendues (de l'autre utilisateur). Au pire (lorsque nous ne parlons pas seulement de mises à jour de formulaires, mais de choses comme l'expédition des commandes), cela peut entraîner des pertes de toutes sortes (temps, revenus, etc.).
L'utilisation d'une stratégie de concurrence permet d'identifier ces cas et de pouvoir les résoudre en fonction des règles métier. Par exemple, Optimistic Concurrency demande à l'utilisateur d'envoyer la version du formulaire qu'il met à jour. Lorsque l'acteur va traiter la modification, il remarque que le 2e utilisateur pense qu'il met à jour la version 5 lorsque le formulaire est réellement à la version 6 en raison de la mise à jour du premier utilisateur. Maintenant, au moins, nous pouvons informer le 2e utilisateur que le formulaire a déjà changé depuis qu'il a commencé à le modifier. Ou quelles que soient les règles que l'entreprise souhaite y appliquer.
Dans le cas de la mise à jour d'un formulaire, vous ne vous souciez probablement pas autant de la concurrence (cela dépend, je suppose). Mais dans d'autres cas, il peut être très important de pouvoir au moins vérifier et gérer les violations. Vous pouvez même ignorer la violation d'accès simultané, comme si les utilisateurs changeaient de sections différentes (pour continuer l'analogie du formulaire). Ou si le changement a un impact important sur l'entreprise (une grosse commande), vous voulez l'accepter et résoudre les conflits mineurs plus tard (par exemple, la mise à jour annuelle des coordonnées n'est pas terminée).
Je crois qu'Akka a un certain nombre d'autres dimensions comme la façon dont il gère les pannes, les superviseurs, etc. qui sont des considérations importantes pour les devops.