Forum: VoltDB Architecture

Post: When is commit returned to client ?

When is commit returned to client ?
gambitg
Oct 6, 2010
Incase of PUTs, there are several points at which VoltDB can return commit to the client:
1. When the PUT has been applied to atleast one node and the rest of the nodes (that hold the same PUT for k-safety) has been notified
2. When the PUT has been applied to all the required nodes (including the redundant partitions for k-safety).


Out of these, at which point is the commit notified to the client ? I know the writes are very fast being in memory, but would like to know if there is a theoretical chance (however remote) of commit happening and transaction being lost on lost of k (or less nodes) going down. (ofcourse loss of more than k nodes does not gaurantee commited data being durable)


Thanks.
Gambitg, Responses are issued
rbetts
Oct 6, 2010
Gambitg,


Responses are issued once all surviving replicas have completed the transaction (option 2). This is true regardless of the content of the transaction - whether it includes only SELECT statements or INSERT/UPDATE statements.


*--Ryan.
will it not be slow?
Nitika
Mar 9, 2011
Gambitg,


Responses are issued once all surviving replicas have completed the transaction (option 2). This is true regardless of the content of the transaction - whether it includes only SELECT statements or INSERT/UPDATE statements.


*--Ryan.


1. If the commit response has to wait for all replicas to commit, won't it be time consuming as there is a network communication involved.
2. If due to any reason the commit fails on any replica then will it rollback on all others.
re: will it not be slow
rbetts
Mar 14, 2011
1. If the commit response has to wait for all replicas to commit, won't it be time consuming as there is a network communication involved.
2. If due to any reason the commit fails on any replica then will it rollback on all others.


For single partition procedures



If the commit response has to wait for all replicas to commit, won't it be time consuming as there is a network communication involved


The data path is: client -> receiving node -> {all involved replica nodes}. And then in reverse back to the client. The communication from the receiving node to the involved replica nodes happens in parallel -- each node is working on the replicated transaction at roughly the same time. In practice, this is not slow.


If due to any reason the commit fails on any replica then will it rollback on all others.


All replicas deterministically calculate the same result. They are doing the same deterministic work from the same consistent starting state.


A VoltDB node can perform from 10k's to 100k's of single partition transactions per second, depending on the complexity of the procedure and the number of CPUs in the node.


For multi-partition procedures


Multi-partition write (insert/delete) procedures are executed a little differently. A multi-partition transaction is essentially two phase committed across the cluster's nodes. One partition replica is chosen as the "coordinator." Other replicas prepare and respond to the coordinator with their prepared state (ok-to-commit, constraint-violation). The coordinator then instructs all replicas to either commit or rollback. There are several optimizations to avoid blocking on the commit message when a replica has performed only reads and has not changed any state.


A VoltDB cluster can perform hundreds of multi-partition procedures per second.


Ryan.
single partition procedures : followup
gambitg
Sep 1, 2011
For single partition procedures


If the commit response has to wait for all replicas to commit, won't it be time consuming as there is a network communication involved


The data path is: client -> receiving node -> {all involved replica nodes}. And then in reverse back to the client. The communication from the receiving node to the involved replica nodes happens in parallel -- each node is working on the replicated transaction at roughly the same time. In practice, this is not slow.


If due to any reason the commit fails on any replica then will it rollback on all others.


All replicas deterministically calculate the same result. They are doing the same deterministic work from the same consistent starting state.


A VoltDB node can perform from 10k's to 100k's of single partition transactions per second, depending on the complexity of the procedure and the number of CPUs in the node.


For multi-partition procedures


Multi-partition write (insert/delete) procedures are executed a little differently. A multi-partition transaction is essentially two phase committed across the cluster's nodes. One partition replica is chosen as the "coordinator." Other replicas prepare and respond to the coordinator with their prepared state (ok-to-commit, constraint-violation). The coordinator then instructs all replicas to either commit or rollback. There are several optimizations to avoid blocking on the commit message when a replica has performed only reads and has not changed any state.


A VoltDB cluster can perform hundreds of multi-partition procedures per second.


Ryan.


For single partition procedures:
Nitika's question is still unanswered: If due to any reason the commit fails on any replica then will it rollback on all others ?


Granted it is fast but there is still a chance that transaction can finish on one replica and not on the other. In that case, does it rollback on the one that completed ?


In my tests, it seemed like it is NOT rolled back and NO error is returned to the client. Is that true ?