[
https://issues.apache.org/jira/browse/OMID-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15803269#comment-15803269
]
James Taylor commented on OMID-56:
----------------------------------
[~ebortnik] - no RPC for {{addDMLFence()}}. It's purely local. It's basically
adding a row key into the change set.
The simplistic approach doesn't solve the problem because the problem is for
transactions that are already in progress on the table. They've already started
a transaction. We need a way of detecting an overlap between the start/end of
the table transaction and the creation of an index on the table. Originally we
though to solve it by having a read and a write lock where the DML operation is
a read lock while the create index is a write lock. A read/read conflict is
fine, but a read/write conflict isn't. Tephra didn't have this capability,
though, so they came up with this alternate solution.
> 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)
