[
https://issues.apache.org/jira/browse/HBASE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667401#comment-13667401
]
Andrew Purtell commented on HBASE-8626:
---------------------------------------
Currently RowMutations should not mix Deletes that dominate some of the Puts
because they will all be given the same timestamp if not otherwise specified by
the client.
bq. I actually meant that we do this only for transactions which contain a mix
of deletes and puts with overlaps like this one.
The semantics _could_ be changed that for all mutations in the RowMutation with
timestamp == HConstants#LATEST_TIMESTAMP as the ops are applied with the row
lock asserted, the mutation processor will substitute timestamps incremented by
1 at each op. (What happens now IIRC is the current time is snapshot into a
long, then packed into a byte[], and reused to set the timestamp of every KV if
its timestamp == HConstants#LATEST_TIMESTAMP.) Then if the client is trying to
structure the RowMutation with Deletes ahead of Puts it would work as expected
even if one of the Deletes may dominate one or more of the Puts. But if we make
that change, then we have to make sure that any other op applied to the row(s)
are not assigned a time in the past relative to those synthetic timestamps.
Depending on the resolution of the system clock, "now" when the RowMutation is
processed and "now" when the next RPC is serviced after the row locks are
released could be the same, and both may address the same same row(s), leading
to weird time travel behavior.
> RowMutations fail when Delete and Put on same columnFamily/column/row
> ---------------------------------------------------------------------
>
> Key: HBASE-8626
> URL: https://issues.apache.org/jira/browse/HBASE-8626
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Affects Versions: 0.94.7, 0.95.0
> Environment: Ubuntu 12.04, HBase 0.94.7
> Reporter: Vinod
> Fix For: 0.94.7, 0.95.1
>
> Attachments: TestRowMutations.java, tests_for_row_mutations1.patch
>
>
> When RowMutations have a Delete followed by Put to same column family or
> columns or rows, only the Delete is happening while the Put is ignored so
> atomicity of RowMutations is broken for such cases.
> Attached is a unit test where the following tests are failing:
> - testDeleteCFThenPutInSameCF: Delete a column family and then Put to same
> column family.
> - testDeleteColumnThenPutSameColumn: Delete a column and then Put to same
> column.
> - testDeleteRowThenPutSameRow: Delete a row and then Put to same row
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
