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

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

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

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

1 Ответ

1 голос
/ 15 апреля 2020
  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. Также читайте Это очень важно!
...