{"id":"4a7bd06e-2b3a-45ea-9911-3059af82c8e5","arxiv_id":"1908.01908","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"WiSer proposes a PROMISE/SERIALIZE commit protocol that avoids a coordinator at commit time and resolves conflicts and aggregation constraints lazily after serialization.","lead":"WiSer is a prototype database system that splits transaction commit into a fast local PROMISE step and a later consensus-based SERIALIZE step. The paper argues this gives high availability and lets analytics run in the same system as transactions for IoT workloads.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Availability claim rests on PROMISE, but Section 2.3 says node departures are unsupported and no failure/partition experiments exist; the HA guarantee is unestablished.","rationale":"The paper is a coherent design-plus-initial-experiments paper: the PROMISE/SERIALIZE split is clearly described, and the throughput/latency experiments give evidence for scalability in a healthy cluster. The reader's weakest_assumption identifies the same load-bearing gap: PROMISE completes with quorum reachability, but true transaction outcome is deferred to SERIALIZE, and Section 2.3 admits node departures are not supported directly. My review agrees and sharpens the point: the abstract's 'highly available' and 'covers node joins and departures' are contradicted by the lack of a replica-takeover mechanism and by the absence of any failure-injection experiments in Section 5. This is not an internal contradiction that would force rejection; it is a missing guarantee and missing evidence, both addressable by adding a recovery protocol and partition/failure evaluation. The CONDITIONAL verdict therefore remains appropriate.","tokens_in":14237,"tokens_out":14270,"duration_ms":155606,"concrete_test":"Run a failure drill: after a transaction reaches PROMISE on node N, kill N (or partition N from the SERIALIZER and Raft leader, while keeping N connected to quorum of its replicas), and observe whether N's replicas serialize the promised delta within a bounded deadline and whether the client receives a definitive commit/abort outcome. If promised transactions remain unresolved until N rejoins, the availability guarantee is conditional on N staying alive and connected, contradicting the abstract's departure-handling claim.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim that WiSer provides 'high availability' depends on PROMISE being a meaningful commit step that does not need a coordinator. But PROMISE only makes a delta durable at a quorum of replicas; the transaction's final outcome is not determined until SERIALIZE, and Section 2.3 explicitly says 'Node departures from the network are not supported directly.' If the originating node dies or is partitioned away from the SERIALIZER, the paper says the problem is 'handled by the node replicas' but does not describe any mechanism for replicas to advance that node's subchain or deliver a final status to clients. The abstract claims WiSer 'covers node joins and departures as database tables,' but Section 2.3 says an unresponsive node cannot be evicted and must rejoin with a new ID. Thus the system can acknowledge transactions that may never serialize or may later roll back, without a demonstrated recovery path. Section 5 contains no partition, failure, or availability experiments; all measurements are on healthy clusters, and the end-to-end experiment does not even include constraint enforcement. The availability guarantee therefore is not established by the paper, and the stated HA claim is stronger than what the design text supports.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents WiSer, a distributed HTAP DBMS that splits transaction commit into a PROMISE stage, during which a transaction's delta is durably replicated to a quorum of nodes without contacting a global coordinator, and a SERIALIZE stage, during which a small Raft-log-based consensus procedure fixes the transaction's position in the serial order. The system embeds read-sets and snapshots into transaction deltas, stores all system and database state in tables, and resolves read-write conflicts and aggregation constraints lazily after serialization. The paper claims that this design provides consistency with high availability, avoids sharding, and enforces aggregation constraints efficiently, and it reports throughput and latency experiments on a healthy 28-node cluster.","tokens_in":14468,"tokens_out":6850,"duration_ms":73261,"significance":"The PROMISE/SERIALIZE decomposition is a genuinely interesting architectural idea that separates client-visible acknowledgment from final serializable commitment, and the 'all state in tables' principle is a clean way to reason about metadata and failure. The work targets a real and current problem—HTAP with aggregation constraints in distributed settings—and the healthy-cluster experiments show good scaling. However, the central availability claim is not demonstrated: node departures are explicitly unsupported, no failure or partition experiments are reported, and the lazy constraint-resolution protocol has a potential correctness gap involving transactions that read data later removed by constraint rollbacks. If these issues are resolved, the work would be a solid contribution to HTAP and transaction-processing design.","major_comments":[{"comment":"The abstract states that WiSer 'covers node joins and departures as database tables,' but Section 2.3 says 'Node departures from the network are not supported directly' and describes no mechanism for replicas to advance the subchain of an unresponsive node or to deliver a final status to clients. Because PROMISE can return to a client before SERIALIZE, a transaction acknowledged at PROMISE on a node that subsequently fails may never be serialized or rolled back. The paper therefore does not establish the liveness of PROMISE-completed transactions under node failure, which directly undermines the central 'high availability' claim. This must be addressed either by adding a concrete recovery protocol or by substantially softening the availability claim.","section":"Section 2.3 and Abstract"},{"comment":"None of the experiments in Section 5 exercise node failure, network partition, or node departure; all measurements in Figures 4–8 are taken on healthy clusters. The abstract and introduction promise availability benefits from PROMISE, but the paper provides no experimental evidence that PROMISE completes in scenarios where a coordinator-based system would block, nor does it analyze the quorum requirement: PROMISE still needs a quorum of replicas, so under a majority partition it cannot complete for at least some nodes. A microbenchmark with injected partitions, and an explicit statement of the partition behavior, are needed to make the HA claim credible.","section":"Section 5"},{"comment":"Constraint resolution can roll back transactions after SERIALIZE, but the paper does not describe how this interacts with already-resolved read-write conflicts. A transaction T2 that is serialized after a constraint-violating transaction T1 may have read T1's writes and have been marked conflict-free at CONFLICT RESOLVE time. If T1 is later removed via the ConstraintFailures table, T2's read result changes, yet T2 is not re-examined. The statement in Section 4.1 that removing violating transactions 'only moves the running aggregate in a beneficial direction, so it is safe for other nodes to ignore this effect' addresses only the aggregate value, not the correctness of previously published transactions that depend on the removed writes. This is a load-bearing correctness gap: the paper needs either a cascading rollback protocol, a re-evaluation of conflict status after constraint resolution, or a proof that such dependencies cannot occur in the proposed execution model.","section":"Section 4.1 and Section 2.1 Stage 5"},{"comment":"The paper's terminology conflates 'commit' with 'PROMISE.' A transaction that completes PROMISE is acknowledged durably, but its final outcome is not known until SERIALIZE, and it may later roll back due to conflicts or constraint violations. The claim that 'the semantics upon such a time-out is identical to that of time-out at commit in a classical DBMS' is not argued: in a classical DBMS, an acknowledged commit implies that the transaction is committed and durable, whereas here a PROMISE-acknowledged transaction can later be aborted. The paper should either introduce a clearer term for this intermediate state or provide a precise statement of what the client is guaranteed at each stage, including under a subsequent node failure.","section":"Section 2.1 Stage 1 and Section 1.2.1"}],"minor_comments":[{"comment":"The text says 'Figure 5 and Figure 5 show...'; the second reference should likely be to Figure 6, which is the plot for the UpdatePrice transaction size of 20.","section":"Section 5.2"},{"comment":"The sentence 'Applications requiring strict serializability can stop at SERIALIZE stage' is confusing because the next paragraphs state that the system waits for publish and constraint resolution before returning a status to the client; clarify what 'stop' means for such applications.","section":"Section 1.2.1"},{"comment":"The sentence 'PROMISE needs no global cluster communication; AP applications stop at this stage' is ambiguous and potentially misleading, because PROMISE still requires a quorum of replicas and the transaction may later roll back. Please rephrase to state exactly what an AP application that 'stops' at PROMISE can rely on.","section":"Section 2.1"},{"comment":"The figures do not include error bars or any measure of variance. For reproducibility, at least a brief statement of run-to-run variability would be helpful, even if error bars are omitted for readability.","section":"Figures 4–8"},{"comment":"Reference [14] is a vendor white paper; consider citing a peer-reviewed description of FaunaDB if one exists, and ensure all references are complete (for example, [32] and [33] are both listed as SIGMOD 2019 entries but with different formatting).","section":"References"}],"recommendation":"major_revision","confidential_remarks":"The paper is more of an architecture/vision paper with preliminary experimental evidence than a fully validated systems contribution. The main blocker is the missing treatment of failure and partition behavior, which is central to the availability claim, and the unresolved correctness interaction between constraint rollback and earlier conflict resolution. I would encourage the authors to address these points with a concrete protocol for node departure and a worked-out correctness argument for the lazy resolution order; the current manuscript is not yet acceptable without that work."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"You should know about this one if you care about HTAP or consensus-based transaction processing. The core idea is to split commit into a PROMISE step that runs without a coordinator and a SERIALIZE step that fixes the serial order via Raft. That split, plus storing read-sets as table rows and serialization numbers as columns, is a genuinely new combination. The paper also gets credit for doing conflict and constraint resolution lazily after serialization, which is how they avoid sharding and still claim to enforce aggregation constraints.\n\nThe experiments show reasonable scaling, and the rollback-rate model in Section 5.2 is a simple probabilistic calculation that matches the observed 1–2% rates. That is a real, if small, validation. The system is coherent and the authors are honest about several limitations.\n\nThe soft spots are where the claims are strongest. The title says \"highly available,\" but the paper never demonstrates that. Section 2.3 says node departures are not supported directly and the only recovery path is \"handled by the node replicas\" plus rejoining with a new ID. There are no partition or failure experiments, and the analysis assumes a quorum is reachable. So the availability guarantee is unestablished. Also, there is no formal correctness argument for the lazy conflict and constraint resolvers, and the end-to-end experiment does not even run the constraint resolver. The abstract's claim that node departures are \"covered as database tables\" is overstated relative to what the text says.\n\nThis is not a desk-reject. It is a promising prototype with a real architectural idea. But a serious referee would push for major revision: formalize the correctness argument, add partition/failure experiments, and test constraint enforcement end to end. If those hold up, this could be a solid systems contribution.","headline":"A clever PROMISE/SERIALIZE split for HTAP without sharding, but the 'highly available' claim is not backed by failure or partition experiments and sits awkwardly with Section 2.3's admission that node departures are not directly supported.","tokens_in":15037,"tokens_out":2282,"would_cite":false,"duration_ms":25236,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"WiSer claims that splitting commit into a coordinator-free PROMISE and a consensus-based SERIALIZE delivers consistency with availability in an unsharded HTAP system.","keywords":["distributed transactions","HTAP","consensus","serializable commit","aggregation constraints","availability","read-write conflicts","Raft"],"falsifier":"Run WiSer under a network partition that separates a transaction node from the current SERIALIZER but not from its own replicas: if no transaction on the partitioned side can ever complete SERIALIZE while the partition persists, then the PROMISE step alone does not deliver availability under the partition, and the availability claim is refuted.","tokens_in":14047,"feed_emoji":"🗄️","tokens_out":5646,"duration_ms":59741,"temperature":0.7,"pith_summary":"The paper argues that the traditional requirement that write transactions synchronize with a coordinator before commit is what forces distributed databases to choose between consistency and availability. WiSer instead splits commit into PROMISE, a durable local acknowledgment that needs no coordinator, and SERIALIZE, a consensus step that fixes the transaction's position in the serial order. This split, the paper claims, gives applications the fast local response they need while still delivering serializability, and it lets a single unsharded system enforce aggregation constraints by resolving conflicts and constraint violations lazily on the serialized state. If the design holds up, IoT applications would no longer need escrow logic or sharding to keep global invariants such as non-negative inventory.","feed_headline":"WiSer splits commit into a local promise and a consensus order","feed_subtitle":"If right, IoT apps can enforce aggregation constraints without sharding or escrow logic.","key_machinery":"The load-bearing mechanism is the symbolic commit: a delta that carries three unresolved placeholders—its position in the serial order, its read-write conflict status, and its aggregation-constraint status—all of which are settled after SERIALIZE. Supporting that mechanism is a data representation in which transaction deltas, including read-sets, are appended to node-local logs, rows are stamped with their serialization sequence number at publish time, and the only consensus log in the system tracks serializer elections rather than data changes. That separation is what turns ordering into a consensus problem while keeping data movement out of the consensus path, and it is what makes lazy, parallel conflict and constraint resolution possible.","core_discovery":"In WiSer's own terms, a transaction is durably recorded at PROMISE without any global coordination, and its delta is later assigned a serialization sequence number by a lightweight Raft log that records only serializer elections, not user data. Because each delta embeds the transaction's read-set and each published row carries its serialization sequence number, the state at the serialization frontier is deterministic; read-write conflicts and aggregation constraint violations can therefore be checked in background, on a non-changing state, and the system need not lock or escrow anything at transaction time. The result is meant to be consistency with availability: strict serializability is available to applications that wait for SERIALIZE, while the PROMISE step provides the fast acknowledgment that interactive and IoT-facing applications expect.","pith_inferences":["The availability delivered by PROMISE is narrower than a classic commit: the client knows the delta is durably stored but cannot act on the outcome until SERIALIZE, so the practical gain is reduced blocking rather than early knowledge of commit.","The same split could be adapted to geo-replicated settings by letting multiple serializers order batches by timestamps, but the paper only sketches a single elected serializer and does not analyze such configurations.","The paper's own experiments show publish is the throughput bottleneck; a natural test is whether batching or columnar reorganization at publish, rather than consensus, dominates end-to-end latency as nodes scale.","Read-sets stored as 64-bit hashes will cause some false-positive rollbacks, so measuring that rate against exact key sets would quantify the cost of the approximate representation the paper acknowledges."],"forward_implications":["Applications can acknowledge a transaction's durability locally at PROMISE and still receive full serializability if they wait for SERIALIZE.","Aggregation constraints like non-negative inventory can be enforced by the DBMS in the background, removing the need for escrow mechanisms and compensating application code.","Because conflict resolution runs on a deterministic, non-changing state after SERIALIZE, it can be parallelized across nodes and can keep up with transaction rates using streaming queries.","Read-write conflicts, including phantoms from range predicates, are handled by comparing embedded read-sets against writes after ordering, avoiding lock-table scans of the database.","Serialization cost is independent of transaction load, so throughput scales by adding transaction nodes, subject to the publish bottleneck the paper reports."],"supporting_citations":[{"why":"Supplies the Raft consensus protocol that gives SERIALIZE its ordering and liveness properties.","marker":"[23]"},{"why":"Calvin is the reference for serializing whole batches and then resolving effects on a deterministic state, which WiSer adapts without pre-analyzing transactions.","marker":"[29]"},{"why":"Wildfire is the prior HTAP prototype WiSer extends, providing the publish and query infrastructure.","marker":"[5]"},{"why":"ARIES/KVL's next-key locking is the phantom-prevention technique that WiSer's range read-sets replace.","marker":"[20]"},{"why":"The LSM-tree is the indexing structure used at publish time for efficient point lookups.","marker":"[22]"}],"fun_headline_variants":["WiSer splits commit: promise first, serialize later","WiSer: fast promise, lazy serialization for IoT","WiSer removes coordinator from IoT transaction commits","WiSer embeds read-sets in deltas for lazy conflict checks"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that a PROMISE acknowledgment from a quorum of replicas, made without contacting the coordinator, provides meaningful availability even though the transaction's true outcome remains undecided until the later SERIALIZE step.","fun_headline_variants_meta":{"raw":{"variants":["WiSer splits commit: promise first, serialize later","WiSer: fast promise, lazy serialization for IoT","WiSer removes coordinator from IoT transaction commits","WiSer embeds read-sets in deltas for lazy conflict checks"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00025,"raw_usage":{"total_tokens":1562,"prompt_tokens":959,"completion_tokens":603,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":575,"completion_tokens_details":{"reasoning_tokens":537}},"tokens_in":575,"tokens_out":603,"duration_ms":6407,"temperature":1.0,"reasoning_tokens":537,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T14:59:36.066044+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run WiSer under a network partition that separates a transaction node from the current SERIALIZER but not from its own replicas: if no transaction on the partitioned side can ever complete SERIALIZE while the partition persists, then the PROMISE step alone does not deliver availability under the partition, and the availability claim is refuted.","supporting_citations":[{"cited_title":"Kallman, H","cited_arxiv_id":null,"evidence_quote":"Supplies the Raft consensus protocol that gives SERIALIZE its ordering and liveness properties."},{"cited_title":"O’Neil, E","cited_arxiv_id":null,"evidence_quote":"Calvin is the reference for serializing whole batches and then resolving effects on a deterministic state, which WiSer adapts without pre-analyzing transactions."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Wildfire is the prior HTAP prototype WiSer extends, providing the publish and query infrastructure."},{"cited_title":"Farber, N","cited_arxiv_id":null,"evidence_quote":"ARIES/KVL's next-key locking is the phantom-prevention technique that WiSer's range read-sets replace."},{"cited_title":"Harding, D","cited_arxiv_id":null,"evidence_quote":"The LSM-tree is the indexing structure used at publish time for efficient point lookups."}],"review_version":1}