Una de las ventajas de los modelos de procesamiento de mensajes, como actores y agentes, es que los problemas tradicionales de concurrencia (principalmente la sincronización del estado compartido) ya no son un problema. El actor puede mantener el estado privado y actualizarlo libremente sin bloqueos. El marco del actor garantiza que solo se procese un mensaje a la vez. Con el procesamiento en serie, el código se puede escribir de forma libre de bloqueo.
En su ejemplo de usuarios que guardan un formulario, suponiendo que el actor mantiene una Lista de algunos datos de cada formulario, el actor puede actualizar la lista sin bloqueos, porque el marco garantiza que solo se procesará un formulario a la vez. Tradicionalmente, tendría que bloquear los accesos a la Lista o usar una lista concurrente.
La estrategia de concurrencia es un asunto ligeramente diferente y sigue siendo su responsabilidad (sin que la estrategia sea la más común). Para cambiar un poco su ejemplo, supongamos que ambos usuarios intentan actualizar la misma instancia de formulario al mismo tiempo. Sin una estrategia de concurrencia, los cambios de uno sobrescribirán al otro (probablemente el último gane). Eso está bien, pero en el mejor de los casos esto resulta en un comportamiento inesperado para el usuario cuyos cambios se sobrescribieron. Si ven el formulario que acaban de cambiar, tendrá valores inesperados (del otro usuario). En el peor de los casos (cuando no solo estamos hablando de actualizaciones de formularios, sino también de pedidos de envío), podría ocasionar pérdidas de varios tipos (tiempo, ingresos, etc.).
El uso de una estrategia de concurrencia ayuda a identificar estos casos y a poder resolverlos según las reglas comerciales. Por ejemplo, Optimistic Concurrency hace que el usuario envíe la versión del formulario que está actualizando. Cuando el actor va a procesar el cambio, se da cuenta de que el segundo usuario piensa que está actualizando la Versión 5 cuando el formulario está realmente en la Versión 6 debido a la actualización del primer usuario. Ahora al menos podemos notificar al segundo usuario que el formulario ya ha cambiado desde que comenzaron a editarlo. O cualesquiera que sean las reglas que el negocio quiera imponer allí.
En el caso de actualizar un formulario, probablemente no le importe tanto la concurrencia (depende, supongo). Pero en otros casos, puede ser algo muy importante al menos poder verificar y manejar las violaciones. Es posible que incluso desee ignorar la infracción de concurrencia, como si los usuarios cambiaran diferentes secciones (para continuar con la analogía del formulario). O si el cambio tiene un gran impacto en el negocio (un pedido grande), desea aceptarlo y resolver conflictos menores más tarde (por ejemplo, la actualización anual de información de contacto no se ha completado).
Creo que Akka tiene otras dimensiones como la forma en que maneja fallas, supervisores, etc., que son consideraciones importantes para los desarrolladores.