[
https://issues.apache.org/jira/browse/OMID-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16849190#comment-16849190
]
Ohad Shacham commented on OMID-147:
-----------------------------------
[~lhofhansl], so we have two problem in here, data that was deleted and should
be gc and transaction that can write "forever" and write the data, in a
previous timestamp, after it was deleted, even though if this transaction will
never be able to commit?
Am I write?
As you said, the first problem should be done by configuration the low
watermark to be max (time interval, timestamp of data evicted from the conflict
map). The second, should be done by adding a suicide mechanism to transactions?
> Discuss better/faster ways of garbage collection during HBase major
> compactions
> -------------------------------------------------------------------------------
>
> Key: OMID-147
> URL: https://issues.apache.org/jira/browse/OMID-147
> Project: Apache Omid
> Issue Type: Wish
> Affects Versions: 1.0.1
> Reporter: Lars Hofhansl
> Priority: Major
>
> *Not for 1.0.1*
> In our use of HBase/Phoenix we very frequently need to delete a lot of data
> (customers leave, we have GDPR requests and various other reasons).
> We need to be able to ensure that data marked for deletion in HBase is
> removed no later than some specific point in time. Currently this is hard to
> achieve - see OMID-142.
> So let's have a discussion here, about how this could happen. Either by some
> manual step, or -preferably - by disconnecting the conflictMap from when a
> transaction's deleted data becomes eligible for physical removal.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
