distributed transaction management docs #276
Conversation
Signed-off-by: John Hosie <[email protected]>
| ### Communication with remote endorsers | ||
|
|
||
| In the single node scenario described earlier in this topic, we discussed the asynchronous request / reply interface to the orchestrator. Communication with one or more remote nodes for endorsement gathering is achieved using this request / reply mechanism and reliable delivery is achieved via the "requester retries" model. There is no need to co-ordinate persistent state across requester and endorser and the endorser can remain stateless. | ||
|
|
There was a problem hiding this comment.
this is contrary to assumptions previously stated (#31 (comment)). Beforehand, we were relying on the endorser never giving a different answer if asked again and we were relying on each individual endorser remembering what transactions it has endorsed to spend which states so that it could prevent 2 conflicting transactions from reaching full endorsement. However, that required the endorser to have persistence which introduces more complexity and performance limitations.
With this new simplifying assumption, there (eventually) is only one co-ordinator for all in-flight transaction that could potentially have contention for state so detection and resolution of contention can be done in memory.
| High level of concurrency is defined as more than one transaction in flight for the same pente contract and therefore there is likely to be a contention for state. In the case of high level of concurrency, given that pente is a 100% endorsement model, all coordinators will detect that other nodes are coordinating transactions and will converge on an agreed single coordinator for the current in-flight transactions. | ||
|
|
||
| In future, it may be possible to optimse the behaviour so that multiple nodes can independently co-ordinate concurrent sequences of transactions for the same pente contract so long as transactions being coordinated by one node do not attempt to call or read private evm contracts that are called by transactions being coordinated by another node. However, that adds complexity esp. when you consider the fact that the contract(s) a transaction will call / read could change when that transaction is re-assembled. So for now, we assume that any 2 concurrent transactions in flight for the same pente contract are likely to cause state contention and will need to be coordinated by the same node. | ||
|
|
There was a problem hiding this comment.
Feel like we should close this topic off with a summary on tenets vs policy.
It would be a purely academic discussion given that there is no way to override the default behaviour but may serve as a useful line in the sand to facilitate future discussion. Tenets are things that the architecture assumes to be true and policy is a behaviour that happens to be a certain case by default but could potentially be tweaked to optimise for certain domains.
Examples of tenets would be
- pending states can only be speculatively spent by transactions being co-ordinated on the same node as the transaction that produces the state.
Examples of policy would be
- co-ordinator selector algorithm
- submitter selector algorithm
Signed-off-by: John Hosie <[email protected]>
Signed-off-by: John Hosie <[email protected]>
|
This PR is stale because it has been open 30 days with no activity. |
|
This PR is stale because it has been open 30 days with no activity. |
No description provided.