Showing posts from May, 2022

Why should this paper be published?

Here is a simple suggestion that will immensely improve the publishing/reviewing experience. Every submission should include a subsection called: "Why should this paper be published?" (WSTPBP). Here, the authors should provide an objective/falsifiable statement of why this paper deserves publication. This may include statements like: this feature of the system is novel (no previous work has it) this is a more {fault-tolerant, secure, efficient, simple} solution than previous solutions This should be a targeted minimal set. If one of these statements is falsified by the reviewers, it could be a valid reason to reject the paper. In that sense, WSTPBP is the authors' contract with the reviewers. The authors put a stake in the ground, saying that the reviewers should focus on the claims in WSTPBP, rather than giving other pretexts, diverging to unclaimed features to reject the paper. This focuses the reviewing process as the reviewers evaluate the paper based on WSTPBP. If th

Feral Concurrency Control: An Empirical Investigation of Modern Application Integrity

The rise of data-intensive “Web 2.0” Internet services has led to popular new Object-Relational Mapping (ORM) programming frameworks. Rather than adopting the use of traditional transactional programming primitives, the ORM framework developers use feral (application-level) mechanisms for maintaining database integrity. They specify declarative correctness criteria/invariants (through validations and associations) and have the ORM enforce the criteria on their behalf. This paper (Sigmod 2015) examines the implications of this impedance mismatch between databases and modern ORM frameworks for application integrity. The paper investigates Rails in depth (and also surveys six additional frameworks) to evaluate the effectiveness of these feral mechanisms in practice and to quantify data integrity violations experimentally. Implications of these for database research are discussed at the end. Ruby on Rails Rails divides application code into Model-View-Controller architecture. Building a

Warp: Lightweight Multi-Key Transactions for Key-Value Stores

This paper introduces a simple yet powerful idea to provide efficient multi-key transactions with ACID semantics on top of a sharded NoSQL data store. The Warp protocol prevents serializability cycles forming between concurrent transactions by forcing them to serialize via a chain communication pattern rather than using a parallel 2PC fan-out/fan-in communication. This avoids hotspots associated with fan-out/fan-in communication and prevents wasted parallel work from contacting multiple other servers when traversing them in serial would surface an invalidation/abortion early on in the serialization. I love the elegance of this idea. As far as I can see, this paper did not get published in any conference. The authors published a followup paper to this in NSDI 16, called "The Design and Implementation of the Warp Transactional Filesystem." But that paper does not talk about the internals of Warp protocol like this archive report, rather talks about the Warp Transactional File

Popular posts from this blog

Graviton2 and Graviton3

Foundational distributed systems papers

Learning a technical subject

Your attitude determines your success

Learning about distributed systems: where to start?

Progress beats perfect

CockroachDB: The Resilient Geo-Distributed SQL Database

Warp: Lightweight Multi-Key Transactions for Key-Value Stores

Amazon Aurora: Design Considerations + On Avoiding Distributed Consensus for I/Os, Commits, and Membership Changes

Anna: A Key-Value Store For Any Scale