[
https://issues.apache.org/jira/browse/HBASE-5203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13186645#comment-13186645
]
Lars Hofhansl commented on HBASE-5203:
--------------------------------------
Because the Delete might come before the Put or vice versa? Put and Delete are
not commutative, their order matters.
I think that is reasonable. Just like from the client you can issue Deletes and
Puts in any order for the same family.
But... Looking at Delete.java, there is some other weirdness there:
When you add a family marker for a family it deletes all column/version markers
for that family, but does not check the timestamp. When can't I issue a Delete
that deletes a family F for time T1 and some columns of that family for time T2
(when T2 > T1)?
Note that the same it true for column makers that hide version markers... In
theory we could remove the version markers too.
If that strange logic would not exist in Delete, this would become simpler. (It
would incidentally also simplify the Import/Copytable MR code).
So the first thing I propose is removing that logic in Delete.java. You can
just add family/column/version markers to a Delete as you please. If we want to
be fancy we can track the latest TS for columnfamily and then remove all
entries if superseded by a family delete marker - but I do not even think that
is necessary.
> Group atomic put/delete operation into a single WALEdit to handle region
> server failures.
> -----------------------------------------------------------------------------------------
>
> Key: HBASE-5203
> URL: https://issues.apache.org/jira/browse/HBASE-5203
> Project: HBase
> Issue Type: Sub-task
> Components: client, coprocessors, regionserver
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Fix For: 0.94.0
>
>
> HBASE-3584 does not not provide fully atomic operation in case of region
> server failures (see explanation there).
> What should happen is that either (1) all edits are applied via a single
> WALEdit, or (2) the WALEdits are applied in async mode and then sync'ed
> together.
> For #1 it is not clear whether it is advisable to manage multiple *different*
> operations (Put/Delete) via a single WAL edit. A quick check reveals that WAL
> replay on region startup would work, but that replication would need to be
> adapted. The refactoring needed would be non-trivial.
> #2 Might actually not work, as another operation could request sync'ing a
> later edit and hence flush these entries out as well.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
