Как я могу повторно активировать Orleans Grain?

Если мне нужно выполнить операцию на уровне сохраняемости за орлеанским набором зерен, как я могу гарантировать, что эти затронутые зерна могут повторно активироваться в соответствии с обновленными данными?

Мой пример: у меня есть гранула на уровне записи Employee (EmployeeID в качестве идентификатора Grain ID), и мне нужно выполнить массовую операцию с некоторыми записями. Очевидно, важно убедиться, что зерна повторно загружаются после этой операции.

Я создал силос Orleans с зерном для выполнения различных операций, в том числе смены сотрудников. Я использую функцию GetGrain, как показано ниже.

var employeeGrain = _clusterClient.GetGrain<IEmployeeGrain>(employeeId, "employee");

Это зерно останется активным, пока оно используется на основе стандартного жизненного цикла Orleans. Мой вопрос: если я сознательно выполняю действие, которое изменяет базовые данные, как мне вызвать повторную активацию затронутых зерен?

Из официальной документации https://dotnet.github.io/orleans/1.5/Documentation/Advanced-Concepts/Activation-Garbage-Collection.html

Кажется, что вы можете заставить отдельное зерно деактивироваться

this.DeactivateOnIdle()

Но если я выполняю более крупную операцию, я бы хотел избежать этого на зерно? Я думаю, в идеале перерабатывать все зерна определенного типа.


.net orleans
person Jon Coello    schedule 27.08.2020    source источник
comment
Джон, добро пожаловать в SO. Не могли бы вы добавить некоторые подробности о том, что вы уже пробовали и что не работает?   -  person vvg    schedule 27.08.2020

Ответы (1)


arrow_upward
4
arrow_downward

Это зерно останется активным, пока оно используется на основе стандартного жизненного цикла Orleans. Мой вопрос в том, что если я сознательно выполняю действие, которое изменяет базовые данные...

Я думаю, вы не совсем понимаете, как работает Орлеан. Вам не разрешено изменять базовые данные без прохождения через зерно, в этом весь смысл. Если вы это сделаете, вы нарушите однопоточное обещание выполнения, которое вам предоставляет Орлеан.

Мне кажется, вы все еще придерживаетесь старой не-актерской модели мышления.

Для Орлеана (или паттерна актера в целом) зернистость нужно модифицировать только через самого актера. Только тогда дается эта гарантия.

Кроме того, акторы также действуют как своего рода горячее кэширование, при котором состояние акторов, к которому недавно обращались, остается в памяти и не требует никакой базы данных. Это работает, потому что зерно обрабатывается только одним потоком в одном бункере, а это означает, что состояние никогда не может быть изменено несколькими потоками одновременно (и, следовательно, не требуется синхронизация или блокировка).

Однопоточное выполнение гарантирует, что один актор будет выполняться только одним потоком в любой момент времени. Это дает Орлеану возможность бесконечного масштабирования, поскольку нет проблем с параллелизмом (однако вы все равно можете столкнуться с взаимоблокировками зерна A, пытающегося получить доступ к зерну B, в то время как зерно B пытается получить доступ к зерну A, и метод не помечен как реентерабельный) .

... как мне вызвать повторную активацию пораженных зерен?

Конечно, вы можете перезапустить разрозненный кластер как часть автономной миграции (на новую модель данных), но я бы предпочел быть осторожным с этим, так как изменение данных за пределами зерна может нарушить любую согласованность и гарантированный инвариант класса делать это. В этом случае вы закрываете кластер, обновляете/переносите существующие данные, развертываете новую версию своего программного обеспечения, а затем запускаете кластер с обновленной моделью.

В качестве альтернативы, если ваши зерна не сохраняют какое-либо состояние (не имеют состояния), вы можете запускать их как зерна без состояния с определенным временем жизни после их деактивации, и их состояние будет обновлено при их следующей активации. Это хорошо работает в сценариях, где Орлеан используется в качестве горячего кэша (т. е. для запуска операции поиска и небольшого кэширования результатов для уменьшения количества обращений к базе данных).

person Tseng    schedule 31.08.2020