Warp is quite interesting, and seemed really promising and ahead of its time. Unfortunately, Hyperdex (which is the key-value store that implements it) has not been maintained for many years [1], and the website is dead.<p>While the technology is impressive, the author seems to have lost interest, and moved on to working on something called Consus [2], which has also been abandoned (no activity 2018).<p>Hyperdex never became popular, and a problem all along was that the author — a very talented developer, from what I can tell — seemed more invested in his projects from the perspective of academic research (he developed Hyperdex at Cornell, I believe) than in delivering a practical, living open source project. He tried to form a company around Hyperdex (the transactional Warp add-on was commercial) even though nobody seemed to be using it; and he was the sole developer. I actually submitted a PR at one point to fix a build problem, but the author was completely unresponsive; you can't really do open source that way.<p>I <i>think</i> the Warp code was actually open sourced when the author realized they had failed to commercialize it, but I'm not sure; it's been a long time.<p>[1] <a href="https://github.com/rescrv/HyperDex/issues/233" rel="nofollow">https://github.com/rescrv/HyperDex/issues/233</a><p>[2] <a href="https://github.com/rescrv/Consus" rel="nofollow">https://github.com/rescrv/Consus</a>
I implemented multiversion concurrency control[1]. I am interested how transactions are implemented without it. You need snapshot isolation too so you cannot read dirty writes and avoid phantom reads.<p>PolarDb sets commit timestamp to null and asynchronously changes the commit timestamp after a commit but has a CTS ring buffer for transactions that are still active. The reading transactions has to check this to see if the transaction is part way through committing.<p>The getting the behaviour of all at once or not at all is an interesting problem to have.<p>I use a database timestamp to solve this problem which is the latest transaction to have committed.<p>I think postgres does something clever with minimum and maximum timestamps on each tuple.<p>[1]: HTTPS://GitHub.com/samsquire/multiversiom-concurrency-control
This system doesn’t support interactive transactions does it? In that the whole read / write set needs to be known up front before a transaction can start being processed? I know that systems like FoundationDB and Calvin/Fauna work similarly and get incredible performance because sequencing is so much easier / lock free. I think those two systems couldn’t be adapted for interactive transactions really (without client side retries) but maybe warp could be which is cool!
Nice: ACID guarantees; 75% of the throughput of the non-transactional key-value store it builds upon; linear scaling; conflict retries. Worth trying IMHO.