Hi Andreas, Thanks very much for the quick response! We will go ahead with this HA approach using CFG_DATA_TX_ZOOKEEPER_QUORUM.
Curtis On Fri, Nov 9, 2018 at 1:08 PM Andreas Neumann <[email protected]> wrote: > Hi Curtis, > > All changes to the transaction state, including in-process transactions, > are captured in the transaction log. When a failover occurs, the new > transaction manager recreates the entire transaction state by replaying the > log from the last snapshot. In-flight transactions should still be able to > commit normally. It could happen, however, that a client rolls back during > the short time that the transaction manager is down. That client would not > be able to notify the tx manager that it has rolled back its transaction. > Such a transaction would time out and become an invalid transaction. > > This is tested (not for failover, but for restart) here: > > https://github.com/apache/incubator-tephra/blob/master/tephra-core/src/test/java/org/apache/tephra/persist/AbstractTransactionStateStorageTest.java#L124 > > Cheers -Andreas > > On Fri, Nov 9, 2018 at 6:17 AM Curtis Howard < > [email protected]> > wrote: > > > Hi, > > > > We are using Tephra to support transactions with Phoenix and would like > to > > configure Tephra in HA mode. > > It seems that one option 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? > > > > Is this the recommended approach? Are the any other settings besides > > CFG_DATA_TX_ZOOKEEPER_QUORUM that we need to consider? > > > > Thank you! > > Curtis > > >
