Могу ли я иметь учетную запись на узле и торговать с этой учетной записью без состояния, оставшегося на узле счета?

Question

Я работаю с аккаунтами Corda. В моем сценарии учетная запись создается на узле M и используется совместно с узлом D. Узел D запускает поток создания состояний, где учетная запись является участником. При моделировании решения транзакция должна быть зарегистрирована на узле D, но не на узле M. Проблема заключается в том, что при использовании учетной записи, принадлежащей узлу M, требуется сеанс узла M. И когда я не выполняю ReceiveFinalityFlow в потоке ответчика, генерируется исключение UnexpectedFlowEndException.

И мне нужно иметь возможность сделать запрос хранилища через accountId.

Вопрос в том, могу ли я иметь учетную запись на узле и торговать с этой учетной записью без сохранения состояния на узле счета?

Answer 1

1. FinalityFlow выдаст ошибку, если вы не предоставите FlowSession для каждого участника (см. здесь ), и в вашем случае учетная запись является участником; поэтому вам нужно предоставить FlowSession для узла M.
2. Поскольку вы передаете FlowSession для узла M, то должен быть поток ответчика, где узел M вызывает ReceiveFinalityFlow; в противном случае ваш поток инициатора зависнет, потому что FinalityFlow выполнит send() для отправки транзакции на M, в то время как M не имеет вызова receive() (который выполняет ReceiveFinalityFlow).
3. Вы можете выполнить требуемое требование, вызвав ReceiveFinalityFlow и установив для входного параметра statesToRecord значение NONE; по умолчанию этот параметр установлен на ONLY_RELEVANT (см. определение потока здесь ). Различные типы StatesToRecord объясняются здесь .
4. Ваш поток респондента должен иметь оператор if, если getOurIdentity() является узлом M, затем вызовите ReceiveFinalityFlow с statesToRecord == NONE (потому что вы не хотите M записывать состояние ), если это узел D, тогда вызовите ReceiveFinalityFlow с statesToRecord == RELEVANT (потому что вы хотите, чтобы D записал состояние).
5. Обратите внимание, что только то, что вы написали ответчик определенным образом, не гарантирует, что узел M выполнит вашу версию; написание потока ответчика обычно является обязанностью другого узла; их разработчики могут написать свою собственную версию респондента, в которой они вызывают ReceiveFinalityFlow с statesToRecord == RELEVANT (то есть узел M будет регистрировать результирующее состояние). Прочитайте первый Это не так в этой статье .
6. После того, как вы реализуете вышеизложенное, напишите потоковый тест, который проверяет этот узел M:
   • Не зарегистрировал результирующую транзакцию в ее хранилище транзакций
   • Didn ' Зарегистрировать полученное состояние в его хранилище
7. Причина, по которой я прошу вас сделать это, заключается в том, что я заметил в коде Корды следующее:
   • ReceiveFinalityFlow звонки ReceiveTransactionFlow здесь
   • ReceiveTransactionFlow звонки ResolveTransactionFlow здесь
   • ResolveTransactionFlow переопределяет statesToRecord с NONE на RELEVANT здесь и это утверждение меня беспокоит; Я просто хочу убедиться, что при установке statesToRecord на NONE в ReceiveFinalityFlow для узла M он не записывает транзакцию или состояние

Дайте мне знать, как обстоят дела go.

Также для запроса по учетной записи прочитайте мою статью в следующих 2 разделах:

1. Поиск Наконец, как вы запрашиваете хранилище по учетной записи?
2. Также читайте Это очень важно!