phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-3860) Implement TAL functionality for Omid
Date Wed, 24 May 2017 17:00:09 GMT

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

James Taylor commented on PHOENIX-3860:
---------------------------------------

bq. Will the coprocessor update the secondary index table with the shadow cell information
once the post commit procedure adds these to the data table?
Seems like we'd want these secondary index updates to go through a TAL method or through the
Omid-backed HTableInterface (but somehow optimize them such that no conflict detection takes
place). All this logic is in PhoenixTransactionalIndexer coprocessor. We could create a different
coprocessor for Omid transactional tables. Or we could change PhoenixTransactionalIndexer
to go through the TAL methods. I think perhaps we may be missing an API in Tephra to have
a region server essentially join a transaction that was started on the client. Unlike with
Omid, writing in Tephra is pretty much like any other HBase write if you use the correct transaction
ID for the timestamp.
bq. I assume that reading always use the tps api? Otherwise, how can we know that the data
was committed? This is also true for reading from the secondary index?
Yes, for reads we always go through the Tephra-backed HTableInterface. We serialize the Tephra
transaction over the wire when we need to read on the server-side. Reads from a secondary
index are exactly like reads from a data table from the POV of HBase.
bq. For now I can use Omid's deletion mark to mark deletion. It is a little different than
Tephra's because we are marking the value as opposed to adding a special qualifier but I guess
it has the same semantics.
The semantics are different. We need both a Cell Delete marker and a Family Delete marker
as they have different semantics. When you issue a SQL DELETE statement, you're deleting entire
rows. When you set a column to null, you're deleting a cell. You can read about the "empty
key value" we add to each row and the purpose of it here: https://phoenix.apache.org/faq.html#Why_empty_key_value

> Implement TAL functionality for Omid
> ------------------------------------
>
>                 Key: PHOENIX-3860
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-3860
>             Project: Phoenix
>          Issue Type: Sub-task
>            Reporter: Ohad Shacham
>            Assignee: Ohad Shacham
>
> Implement TAL functionality for Omid in order to be able to use Omid as Phoenix's transaction
processing engine. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message