accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Turner (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-3044) ConditionalMutation should support conditional updates
Date Wed, 06 Aug 2014 21:11:12 GMT


Keith Turner commented on ACCUMULO-3044:

[~ryanleary] I think the optimizations you wanted for processing multiple mutations for the
same row could be achieved by writing to a scratch space and avoiding the walog until the
end.  Checking conditions would read from this scratch space (or a merged view of the scratch
space + tablets data).  So the workflow would look like the following.

 # lock R1
 # create scratch space SP1
 # using SP1 check conditions for CM1, checks pass
 # write CM1 to SP1
 # using SP1 check conditions for CM2, checks pass
 # write CM2 to SP1
 # using SP1 check conditions for CM3, checks pass
 # write CM3 to SP1
 # persist SP1 in walog and update tablets in memory map.   
 # unlock R1

> ConditionalMutation should support conditional updates
> ------------------------------------------------------
>                 Key: ACCUMULO-3044
>                 URL:
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: client, tserver
>    Affects Versions: 1.6.0
>            Reporter: Ryan Leary
> Currently, the ConditionalMutation object operates on a single row, and applies updates
if and only if a set of Conditions are met. 
> A new type of ConditionalMutation which operates on a single row and applies an update
if and only if a set of Conditions for that particular update would be more flexible.
> This behavior is possible currently by creating a new ConditionalMutation for each update.
In the case where there are a large number of updates for a single row, however, there is
a steep penalty paid due to the row-level locking. Another acceptable solution to this ticket
would be optimizing the ConditionalWriter to apply multiple conditional mutations on the same
row within the same atomic lock. The order of execution would need to be guaranteed.
> The API would look something like:
> {code}
> ConditionalMutation cm = new ConditionalMutation(rowKey);
> cm.put(Iterable<Condition>, CF, CQ, CV, Val);
> {code}

This message was sent by Atlassian JIRA

View raw message