Hi,

As noted in the Janus docs: https://docs.janusgraph.org/advanced-topics/eventual-consistency/

"In order to avoid that write failures result in permanent inconsistencies in the graph it is recommended to use storage backends that support batch write atomicity and to ensure that write atomicity is enabled."

Which is great advice assuming the HBase backend supported that option...

I have designed and implemented a version of the HBase backend that has transactional support and uses a WAL to guarantee atomic commits to HBase. In terms of ACID support, it guarantees A, I, and D. It provides only eventual consistency, although in practice the time when things are not consistent is extremely short.

Of course, this could also have all been done by integrating something like Tephra into the HBase backend. The reason why I went the custom algorithm route was because I did not want to add the additional requirement for users to run a Tephra server.

Two questions:

1. Is there any interest in taking this as a contrib?

2. What am I missing here in terms of avoiding inconsistency? What types of inconsistencies can still happen with a transactional backend?

Thanks,

Mike