[
https://issues.apache.org/jira/browse/OMID-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15797351#comment-15797351
]
Ohad Shacham commented on OMID-56:
----------------------------------
Hi [~jamestaylor]
We went over the code to see how to define an interface that connects Omid to
Phoenix.
There are some issues we don't fully understand and it would be great if these
could be clarified.
We saw that Tephra implemented a fencing mechanism in their VisibilityFence
that is being used in Phoenix's MutationState.
We also found Jiras that describe the requirement for stronger consistency due
to the creation of secondary index while upsert instructions are running.
We are not sure we fully understand the problem details and the semantics needs
from these fences. Could you please elaborate on this issue?
Another thing we do not fully understand is the use of both context and awares
in MutationState. There is some comment noting that the context is not thread
safe. Could you please explain this requirement as well?
Thx,
Ohad
> 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)
