[ 
https://issues.apache.org/jira/browse/HBASE-13415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14486110#comment-14486110
 ] 

Keith Turner commented on HBASE-13415:
--------------------------------------

Accumulo's FATE handles this by having the four thrift calls for submitting 
FATE operations.  Its safe for a client to make each thrift call multiple times 
until it succeeds.  The main difference with what proposed here is that the 
master generates a transaction ID instead of a client generating a nonce.  

 * A thrift call to the Accumulo master get a new FATE transaction ID.  This 
creates a new FATE transaction in zookeeper with no work to do. 
 * A thrift call to seed a fate transaction with work.  This call takes the 
transaction ID and an operation (like create table). 
 * A thrift call to wait on a FATE transaction to complete.   This call takes a 
transaction ID and returns any failure info.
 * A thrift call to delete the status information about a completed FATE 
transaction.
 
 

> Procedure V2 - Use nonces for double submits from client
> --------------------------------------------------------
>
>                 Key: HBASE-13415
>                 URL: https://issues.apache.org/jira/browse/HBASE-13415
>             Project: HBase
>          Issue Type: Sub-task
>          Components: master
>            Reporter: Enis Soztutar
>
> The client can submit a procedure, but before getting the procId back, the 
> master might fail. In this case, the client request will fail and the client 
> will re-submit the request. If 1.1 client or if there is no contention for 
> the table lock, the time window is pretty small, but still might happen. 
> If the proc was accepted and stored in the procedure store, a re-submit from 
> the client will add another procedure, which will execute after the first 
> one. The first one will likely succeed, and the second one will fail (for 
> example in the case of create table, the second one will throw 
> TableExistsException). 
> One idea is to use client generated nonces (that we already have) to guard 
> against these cases. The client will submit the request with the nonce and 
> the nonce will be saved together with the procedure in the store. In case of 
> a double submit, the nonce-cache is checked and the procId of the original 
> request is returned. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to