[
https://issues.apache.org/jira/browse/OMID-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15800807#comment-15800807
]
Edward Bortnikov commented on OMID-56:
--------------------------------------
[~jamestaylor] - a couple of naive questions on my side. Is
<code>addDMLFence()</code> a purely local operation, or does it translate to an
RPC call? In the latter case, is it used always - or only in a retry scenario?
The concern is of course having a latency overhead - we try hard to avoid it,
in many places.
Is there a problem with the following simplistic approach. When you start
creating an index - create a DDL lock. This will translate into the TSO
shooting down any transaction trying to write to the table. The client will get
the appropriate error code, and may retry. This does not require any DML fence.
It's possible to imagine a situation in which the writes are starved by CREATE
INDEX for a while, but isn't it similar to other relational databases?
Thanks.
> Integrate with Apache Phoenix
> -----------------------------
>
> Key: OMID-56
> URL: https://issues.apache.org/jira/browse/OMID-56
> Project: Apache Omid
> Issue Type: Improvement
> Reporter: James Taylor
> Labels: phoenix
>
> The current transaction implementation in Phoenix uses Tephra which is good
> when the number of rows in the transaction is small and the changes of a
> conflict are relatively rare. It's also not clear when the number of
> simultaneous transactions would max out given the single, global transaction
> manager component.
> Omid is very complimentary in this regard. Though the overhead for small
> transactions may be larger than Tephra, it will likely scale well as the
> number of rows in a transaction grows and has no global transaction manager.
> It'd be great to figure out the best way to integrate Omid with Phoenix. The
> trickiest issue may be with optimizing secondary indexes, in that conflict
> detection is not necessary for them. We could leave this optimization for the
> future and just treat them as any other HBase table. Perhaps a good first
> step would be to just turn on Omid transactions at the HBase level and then
> have Phoenix issue the appropriate Omid call for start transaction, commit
> transaction, and rollback transaction. It might just work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
