accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-3530) alterTable/NamespaceProperty should use Fate locks
Date Mon, 26 Jan 2015 17:48:34 GMT

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

Christopher Tubbs commented on ACCUMULO-3530:
---------------------------------------------

No, I don't have a particular case in mind. I just want to understand the mechanism by which
this proposal will "help ensure consistency".

At first glance, it does not seem to me that fate locks have anything to do with ZK property
consistency.

The use case you describe seems like it would be satisfied with ACCUMULO-1568

> alterTable/NamespaceProperty should use Fate locks
> --------------------------------------------------
>
>                 Key: ACCUMULO-3530
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3530
>             Project: Accumulo
>          Issue Type: Bug
>            Reporter: John Vines
>
> Fate operations, such as clone table, have logic in place to ensure consistency as the
operation occurs. However, operaitons like alterTableProperty can still interfere because
there is no locking done. We should add identical locking to these methods in MasterClientServiceHandler
to help ensure consistency.



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

Mime
View raw message