This is with reference to the question "Query Data In Notary Node and Query Transaction in Normal Node"
In the above link, only querying normal node has been answered. However, I need to know, how to query the notary node ?
Notary does not know the concept of a cordapp. Hence, all your flow query will not work on a notary node.
All of the crash shell methods so still work in the Notart node shell, but again, since it does not know what a state is, you cannot really query anything from the shell neither.
Related
Does anyone know what happens when two nodes try to write data at the same time and both initiate the 2PC protocol? Does a request from one node get aborted and another one succeed? The failed node would retry with some exponential backoff?
If not, what happens?
Usually resource managers does not allow both nodes to participate in the same transaction in the same transaction branch at the same time. Probably second node/binary/thread which tries to join to the transaction will get timeout or some other error on xa_start(..., TMJOIN) call.
I need to check how the notary prevents the double spending in the Obligation Cordapp. I started the web server UI at the localhost ports and performed some multiple transactions and when I checked the notary's log ,I found this:
[WARN ] 2020-06-24T08:29:33,484Z [Notary request queue processor] transactions.PersistentUniquenessProvider. - Unable to notarise: One or more input states or referenced states have already been used as input states in other transactions. Conflicting state count: 1, consumption details:
7CF1BCA8EDF25F0602BBEDF8AD41FD60336F65EAC09C5326478A4CB7CD620579(0) -> StateConsumptionDetails(hashOfTransactionId=46552C5CE153712B65585A75C4D165CD4A05304564C8797ACEF317DCD925B72E, type=INPUT_STATE).
To find out if any of the conflicting transactions have been generated by this node you can use the hashLookup Corda shell command. [errorCode=1g4005y, moreInformationAt=https://errors.corda.net/OS/4.5-RC02/1g4005y]
net.corda.core.internal.notary.NotaryInternalException: Unable to notarise: One or more input states or referenced states have already been used as input states in other transactions. Conflicting state count: 1, consumption details:
7CF1BCA8EDF25F0602BBEDF8AD41FD60336F65EAC09C5326478A4CB7CD620579(0) -> StateConsumptionDetails(hashOfTransactionId=46552C5CE153712B65585A75C4D165CD4A05304564C8797ACEF317DCD925B72E, type=INPUT_STATE).
To find out if any of the conflicting transactions have been generated by this node you can use the hashLookup Corda shell command.
I performed hashLookup on the invalid txId and found this :
hashLookup 46552C5CE153712B65585A75C4D165CD4A05304564C8797ACEF317DCD925B72E
Found a matching transaction with Id: A86E3ECE4EC12A487E413E2BDAB9D88BFEBCB418FA0224189DE0C72BBBD34B12
I believe this is how notary has stopped the double spending. But I am unable to recreate that testing.Can someone tell me what possible input transaction has led to this error.I mean what test case can lead to this testing of double spend that is stopped by notary?
A notary is a network service that provides uniqueness consensus by attesting that, for a given transaction, it has not already signed other transactions that consumes any of the proposed transaction’s input states.
In other words, the notary will keep track of all the input states (only stores their hashes, not the real state) that are used in transactions, so when someone is trying to use these already-spent inputs, the notary will reject the transaction.
Hence, preventing the double spend.
i am using the https://github.com/corda/corda-tut2-solution-kotlin template for my simple corda app. i have modified it with some addition fields in IOU but i dont want to send to PartyB. i just want to push data over blockchain. I have modified the flows.kt and StateAndContracts.kt source files. but i am unable to do so. i still see the transactions goes to PartyB as well.
Can someone please suggest.
As part of FinalityFlow, a transaction is sent to all the participants of all the transaction's input and output states. I assume in your case, PartyB is one of the participants in the output, so they receive the transaction.
Note that even if you were to remove PartyB as a participant on the output, they would still receive a copy of the full transaction because they are a participant on the input (although they would not store this output state in their vault). We are doing work with SGX (see https://docs.corda.net/head/design/sgx-integration/design.html) to make it so that PartyB would not be able to see the output state at all, even though they are a participant of the input.
need to implement corda node which is pure observer means which persist states but wont participate with other nodes for any transaction.
In order to acheive it i did followning thing:
Made 3 nodes as follow:
PartyA - Nodes contain cordApp jar including transactional flow, observerflow and Contract and states
PartyB - Nodes contain cordApp jar including transactional flow, observerflow and Contract and states
Observer - Nodes contain contract and State along with observer flow only.
On observer node all transactional nodes removed intentionally so that observer wont able to transact with other node.
After nodes start up, performed transaction from PartyA to PartyB by keeping Observer node as observer. It works perfectly.
Now i tried same thing from PartyA to observer and keep PartyB as observer. I expected transaction will get failed but transaction got committed on observer node even though observer node has no transactional flows.
When i tried to perform transaction from observer to PartyA then it gives error as no flow found which is expected.
Example i am using have ownable state and simple initiating flows are used.
My question is how one directional transaction worked with observer inspite of no flows on observer.
How can i prevent observer from not doing any transaction with other nodes, just act as pure observer.
As of Corda 3, the node actually installs default flow responders when it starts up for the four following flows:
FinalityFlow
NotaryChangeFlow
ContractUpgradeFlow.Initiate
SwapIdentitiesFlow
This is done in AbstractNode.installCoreFlows:
private fun installCoreFlows() {
installCoreFlow(FinalityFlow::class, ::FinalityHandler)
installCoreFlow(NotaryChangeFlow::class, ::NotaryChangeHandler)
installCoreFlow(ContractUpgradeFlow.Initiate::class, ::ContractUpgradeHandler)
installCoreFlow(SwapIdentitiesFlow::class, ::SwapIdentitiesHandler)
}
Thus the observer node will still be able to receive and record transactions as part of calls to FinalityFlow.
In a future version of Corda, this default FinalityFlow handler will be removed. Nodes will have to explicitly create a flow that receives and stores a transaction, allowing you to implement the behaviour above.
Within alfresco, I want to delete a node but I don't want to be used by any other users in a cluster environment.
I know that I will use LockService for lock a node (in a cluster environment) as in the folloing lines:
lockService.lock(deleteNode);
nodeService.deleteNode(deleteNode);
lockService.unlock(deleteNode);
the last line may cause an exception because the node has already been deleted, and indeed it causes the exception is
A system error happened during the operation: Node does not exist: workspace://SpacesStore/cb6473ed-1f0c-4fa3-bfdf-8f0bc86f3a12
So how to ensure concurrency in a cluster environment when delete a node to prevent two users to access the same node at the same time one of them want to update it and the second once want o delete it?
Depending on your cluster environment (e.g. same DB server used by all Alfresco instances), transactions might most likely just be enough to ensure no stale content is used:
serverA(readNode)
serverB(deleteNode)
serverA(updateNode) <--- transaction failure
The JobLockService allows more control in case of more complex operations, which might involve multiple, dynamic nodes (or no nodes at all, e.g. sending emails or similar):
serverA(acquireLock)
serverB(acquireLock) <--- wait for the lock to be released
serverA(readNode1)
serverA(if something then updateNode2)
serverA(updateNode1)
serverA(releaseLock)
serverB(readNode2)
serverB(releaseLock)