[
https://issues.apache.org/jira/browse/OMID-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15809363#comment-15809363
]
Ohad Shacham commented on OMID-56:
----------------------------------
Thanks for your answers [~giacomotaylor]
Can we define the semantics of a create index transaction as one that never
aborts? Such a transaction will only make other inflight transaction abort and
will abort only in case of a transaction manager failure.
In this case, we can define a map inside the TSO that maps a table to the
timestamp of the transaction that creates the index and use this timestamp to
abort any DML operation that started before this timestamp. For this case, we
can augment the begin operation with a Boolean flag denote of a create index
transaction (super transaction). We can also hold additional information at the
TSO, if needed, to handle cases where the DML operation started after the
create index and committed before.
This will simplify the process at the client size, especially for Omid that do
not propagate information regarding inflight transaction to the client side
(and also does not have this info at the TM side).
> 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)
