"2) Overview: In essence, the protocol calls for each data item to maintain the last committed and perhaps also the currently active version, for the data and relevant metadata. Each version is tagged with meta-data pertaining to the transaction that created it. This includes the transaction commit time and transaction identifier that created it, pointing to a globally visible transaction status record (TSR) using a Universal Resource Identifier (URI). The TSR is used by the client to determine which version of the data item to use when reading it, and so that transaction commit can happen just by updating (in one step) the TSR. The transaction identifier, stored in the form of a URI, allows any client regardless of its location to inspect it the TSR in order to determine the transaction commitment state. Using the status of the TSR, any failure can be either rolled forward to the later version, or rolled back to the previous version. The test-andset capability on each item is used to determine a consistent winner when multiple transactions attempt concurrent activity on a conflicting set of items. A global order is put on the records, through a consistent hash of the record identifiers, and used when updating in order to prevent deadlocks. This approach is optimized to permit parallel processing of the commit activity."
It seems to be a sort of log-structure/append/change tracking storage where multiple versions of the data to be updated are tracked as transactions are applied to them, and therefore can be rolled back. Probably all active versions are read and then reduced to the final product once all transactions are accounted for. Of course you can't have perpetual transaction changes stored so they must be ... compacted ... at some point? .... which is basically what cassandra does at the node level in the read/write path with LSM, bloom filters, and merging data across disparate sstables...? The devil is in the details of these things of course. Is that about right? On Tue, Nov 13, 2018 at 9:54 AM Ariel Weisberg <ar...@weisberg.ws> wrote: > Hi, > > Fanastic news! > > Ariel > > On Tue, Nov 13, 2018, at 10:36 AM, Hiroyuki Yamada wrote: > > Hi all, > > > > I am happy to release it under Apache 2 license now. > > https://github.com/scalar-labs/scalardb > > > > It passes not only jepsen but also our-built destructive testing. > > For jepsen tests, please check the following. > > https://github.com/scalar-labs/scalardb/tree/master/jepsen/scalardb > > > > Also, as Yuji mentioned the other day, we also fixed/updated jepsen > > tests for C* to make it work with the latest C* version properly and > > follow the new style. > > https://github.com/scalar-labs/jepsen/tree/cassandra > > > > In addition to that, we fixed/updated cassaforte used in the jepsen > > tests for C* to make it work with the latest java driver since > > cassaforte is not really maintained any more. > > https://github.com/scalar-labs/cassaforte/tree/driver-3.0-for-jepsen > > > > We are pleased to be able to contribute to the community by the above > updates. > > Please give us any feedbacks or questions. > > > > Thanks, > > Hiro > > > > > > On Wed, Oct 17, 2018 at 8:52 AM Hiroyuki Yamada <mogwa...@gmail.com> > wrote: > > > > > > Hi all, > > > > > > Thank you for the comments and feedbacks. > > > > > > As Jonathan pointed out, it relies on LWT and uses the protocol > > > proposed in the paper. > > > Please read the design document for more detail. > > > https://github.com/scalar-labs/scalardb/blob/master/docs/design.md > > > > > > Regarding the licensing, we are thinking of releasing it with Apache 2 > > > if lots of developers are interested in it. > > > > > > Best regards, > > > Hiroyuki > > > On Wed, Oct 17, 2018 at 3:13 AM Jonathan Ellis <jbel...@gmail.com> > wrote: > > > > > > > > Which was followed up by > https://www.researchgate.net/profile/Akon_Dey/publication/282156834_Scalable_Distributed_Transactions_across_Heterogeneous_Stores/links/56058b9608ae5e8e3f32b98d.pdf > > > > > > > > On Tue, Oct 16, 2018 at 1:02 PM Jonathan Ellis <jbel...@gmail.com> > wrote: > > > >> > > > >> It looks like it's based on this: > http://www.vldb.org/pvldb/vol6/p1434-dey.pdf > > > >> > > > >> On Tue, Oct 16, 2018 at 11:37 AM Ariel Weisberg <ar...@weisberg.ws> > wrote: > > > >>> > > > >>> Hi, > > > >>> > > > >>> Yes this does sound great. Does this rely on Cassandra's internal > SERIAL consistency and CAS functionality or is that implemented at a higher > level? > > > >>> > > > >>> Regards, > > > >>> Ariel > > > >>> > > > >>> On Tue, Oct 16, 2018, at 12:31 PM, Jeff Jirsa wrote: > > > >>> > This is great! > > > >>> > > > > >>> > -- > > > >>> > Jeff Jirsa > > > >>> > > > > >>> > > > > >>> > > On Oct 16, 2018, at 5:47 PM, Hiroyuki Yamada < > mogwa...@gmail.com> wrote: > > > >>> > > > > > >>> > > Hi all, > > > >>> > > > > > >>> > > # Sorry, I accidentally emailed the following to dev@, so > re-sending to here. > > > >>> > > > > > >>> > > We have been working on ACID-compliant transaction library on > top of > > > >>> > > Cassandra called Scalar DB, > > > >>> > > and are pleased to announce the release of v.1.0 RC version in > open source. > > > >>> > > > > > >>> > > https://github.com/scalar-labs/scalardb/ > > > >>> > > > > > >>> > > Scalar DB is a library that provides a distributed storage > abstraction > > > >>> > > and client-coordinated distributed transaction on the storage, > > > >>> > > and makes non-ACID distributed database/storage ACID-compliant. > > > >>> > > And Cassandra is the first supported database implementation. > > > >>> > > > > > >>> > > It's been internally tested intensively and is jepsen-passed. > > > >>> > > (see jepsen directory for more detail) > > > >>> > > If you are looking for ACID transaction capability on top of > cassandra, > > > >>> > > Please take a look and give us a feedback or contribution. > > > >>> > > > > > >>> > > Best regards, > > > >>> > > Hiroyuki Yamada > > > >>> > > > > > >>> > > > --------------------------------------------------------------------- > > > >>> > > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > > > >>> > > For additional commands, e-mail: > user-h...@cassandra.apache.org > > > >>> > > > > > >>> > > > > >>> > > --------------------------------------------------------------------- > > > >>> > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > > > >>> > For additional commands, e-mail: user-h...@cassandra.apache.org > > > >>> > > > > >>> > > > >>> > --------------------------------------------------------------------- > > > >>> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > > > >>> For additional commands, e-mail: user-h...@cassandra.apache.org > > > >>> > > > >> > > > >> > > > >> -- > > > >> Jonathan Ellis > > > >> co-founder, http://www.datastax.com > > > >> @spyced > > > > > > > > > > > > > > > > -- > > > > Jonathan Ellis > > > > co-founder, http://www.datastax.com > > > > @spyced > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: user-h...@cassandra.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > For additional commands, e-mail: user-h...@cassandra.apache.org > >
