[
https://issues.apache.org/jira/browse/PHOENIX-3860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16021429#comment-16021429
]
James Taylor commented on PHOENIX-3860:
---------------------------------------
bq. These functions use Tephra's family delete marker directly and not using
the tps api. Could you please let me know what is the reason for that?
It's an implementation detail with Tephra which attempts to translate a Delete
to the Tephra delete marker on the server-side in the coprocessor. This is too
late for this translation and causes problems with index maintenance
coprocessors and the way they interact with the Tephra coprocessors. It's
possible that the translation could be done on the client side in the
transactional HTable implementation (TransactionAwareHTable for Tephra)
bq. What is the advantages of using the table directly v.s. the transaction
processor api?
We bypass the transaction process when we write to the secondary index table
(both for the initial index population and for the index maintenance), but we
use the same timestamp from the corresponding data table cell. The reason we do
this for the initial population is because we need to write the cells with a
timestamp of when the index was created. While this population is taking place,
subsequent writes may be occurring at a later timestamp through the normal
index maintenance code path (we're essentially back filling the index rows).
For index maintenance, we bypass the transaction APIs because we're writing
cells on the server side, potentially in parallel across region servers, at a
timestamp that matches the data table cells and have no need to do conflict
detection (since conflict detection is done on the data table which is
sufficient).
> 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)
