Hi Curtis, Omid does provide high availability for transactions, you can find the full technical details in here: https://www.usenix.org/conference/fast17/technical-sessions/presentation/shacham In a nutshell, in-flight transactions in this case are aborted by the transaction manager, they are identified since every transaction manager starts a new epoch. We also have an invalidation mechanism to guarantee snapshot isolation and this guarantees that high availability does not incur any overhead in the mainstream execution.
We are currently at the final stages of the integration with Phoenix and will start a dedicated release in Omid in a few days. Thx, Ohad On Mon, Nov 5, 2018 at 7:15 PM Curtis Howard <curtis.james.how...@gmail.com> wrote: > Hi, > > Is there a best approach to ensuring high-availability for transactions? > It seems that one option when using Tephra could be through the > CFG_DATA_TX_ZOOKEEPER_QUORUM > property: > > https://github.com/apache/incubator-tephra/blob/d0a1c4c295fd28e68223db220b13dc1b12b326da/tephra-core/src/main/java/org/apache/tephra/TxConstants.java#L224-L226 > > I've tested this with a couple of Tephra manager processes on different > hosts, and they do seem to pass off control as the leader/standby > instance. It's not clear to me though how "in-flight" transactions that > have been initiated but not committed yet would be handled during a > failover? > > I also see that there has been recent integration work with Apache Omid as > an alternative transaction manager - is it expected that Omid will (or > maybe does already) provide high-availability for transactions? > > Thanks! > Curtis > > >
