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

Marshall McMullen commented on ZOOKEEPER-965:
---------------------------------------------

So I'm finally getting a chance to circle back around to Benjamin's comments 
above about the stale ChangeRecords that get left in PrepRequestProcessor on a 
failed multi-op. I want to be sure I understand what needs to be done here, so 
Benjamin, feel free to correct me if I'm off track here.... 

You mentioned:

> we have to update both the list and hashmap of pending operations.

If I'm reading this right, this is all currently updated via addChangeRecord 
(in PrepRequestProcess). I think it's adding it to the list via 
zks.outstandingChanges.add(c) and adding to the hashmap via 
zks.outstandingChangesForPath.put(c.path, c). So, adding in a 
removeChangeRecord method here that mirrors addChangeRecord looks like a good 
approach. I think I can use the transaction id on the failed multi op to 
identify all the failed change requests that need to be removed. Luckily, all 
change requests associated with a multiop will have the same txn id, so that 
should be super helpful here.

Also, you mentioned :

> we also need to be careful since the pending operations are modified by the 
> thread executing Finalrequestprocessor

Can you elaborate on what the concern is there? If I make the 
removeChangeRecord synchronized like addChangeRecord is, will that be 
sufficient?



> Need a multi-update command to allow multiple znodes to be updated safely
> -------------------------------------------------------------------------
>
>                 Key: ZOOKEEPER-965
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-965
>             Project: ZooKeeper
>          Issue Type: Bug
>    Affects Versions: 3.3.3
>            Reporter: Ted Dunning
>            Assignee: Ted Dunning
>             Fix For: 3.4.0
>
>         Attachments: ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch
>
>
> The basic idea is to have a single method called "multi" that will accept a 
> list of create, delete, update or check objects each of which has a desired 
> version or file state in the case of create.  If all of the version and 
> existence constraints can be satisfied, then all updates will be done 
> atomically.
> Two API styles have been suggested.  One has a list as above and the other 
> style has a "Transaction" that allows builder-like methods to build a set of 
> updates and a commit method to finalize the transaction.  This can trivially 
> be reduced to the first kind of API so the list based API style should be 
> considered the primitive and the builder style should be implemented as 
> syntactic sugar.
> The total size of all the data in all updates and creates in a single 
> transaction should be limited to 1MB.
> Implementation-wise this capability can be done using standard ZK internals.  
> The changes include:
> - update to ZK clients to all the new call
> - additional wire level request
> - on the server, in the code that converts transactions to idempotent form, 
> the code should be slightly extended to convert a list of operations to 
> idempotent form.
> - on the client, a down-rev server that rejects the multi-update should be 
> detected gracefully and an informative exception should be thrown.
> To facilitate shared development, I have established a github repository at 
> https://github.com/tdunning/zookeeper  and am happy to extend committer 
> status to anyone who agrees to donate their code back to Apache.  The final 
> patch will be attached to this bug as normal.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to