[
https://issues.apache.org/jira/browse/CASSANDRA-21728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18124723#comment-18124723
]
Benedict Elliott Smith commented on CASSANDRA-21728:
----------------------------------------------------
Hi [~madhusasidhar], thanks for the bug report - and for testing out Accord.
TTL integration is currently unvalidated, so we appreciate the feedback and
will take a look. If you encounter any problems with accord the best place to
get help is in the cassandra-accord slack channel, as I don't actively monitor
Jira.
> Accord: literal INSERT in BEGIN TRANSACTION is immediately unreadable with
> table default TTL (6.0-alpha2)
> ---------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-21728
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21728
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Accord
> Reporter: Madhu Sasidhar
> Priority: Normal
>
> On unmodified Apache Cassandra 6.0-alpha2, an ordinary INSERT into a table
> with
> `transactional_mode='full'` and `default_time_to_live=7200` produces a
> readable row
> with TTL 7200. Inserting the same payload at a different key inside an
> explicit
> `BEGIN TRANSACTION ... COMMIT TRANSACTION` returns without an error, but an
> immediate SELECT returns no row. Both operations target the same table and
> node.
> *Environment*
> - Cassandra: official 6.0-alpha2 binary, no server source/JAR modifications.
> Corresponding source revision: `e874e3a90b1942b945477e6d9ba03880b4f4a19d`.
> - Cassandra JAR SHA-256:
> `ee3ff71538369ec3c07cfb15ebcf1fdbecbbb5045d91a5c67d77dea686908aaf`.
> - One node, Ubuntu 24.04 container on Docker Desktop/WSL2 on Windows;
> Eclipse Temurin 21.0.12+8 server JVM; two CPUs/three GiB container limit.
> - Accord enabled; one queue shard and one command-store shard. Replication
> factor 1; transport table uses TWCS and table-default TTL 7200.
> - Client: Apache Cassandra Java driver 4.19.0 on Temurin 25.0.4.1+1, native
> protocol V5, QUORUM/SERIAL, server-side timestamp generator, no explicit
> query timestamp or now-in-seconds override, no request retries or speculative
> execution.
> - Synthetic two-byte blob payload; no application logic, concurrent writes,
> manual flush, repair, restart or compaction request during the comparison.
> - Verified affected version: {*}{{*}}6.0-alpha2 only{{*}}{*}. Current trunk
> and later builds have not been tested.
> *Reproduction*
> Start with an otherwise ready Cassandra 6.0-alpha2 node with Accord enabled.
> Submit the entire BEGIN/COMMIT block as {*}one native CQL request{*}.
> ```sql
> CREATE KEYSPACE probe_2ffad4464d834130
> WITH replication = \{'class':'SimpleStrategy','replication_factor':1};
> CREATE TABLE probe_2ffad4464d834130.transport_full
> (address blob PRIMARY KEY, payload blob)
> WITH transactional_mode='full'
> AND default_time_to_live=7200
> AND compaction=\{'class':'TimeWindowCompactionStrategy'};
> INSERT INTO probe_2ffad4464d834130.transport_full
> (address,payload) VALUES (0x02,0x1122);
> SELECT address, payload, ttl(payload) AS remaining_ttl,
> writetime(payload) AS write_micros
> FROM probe_2ffad4464d834130.transport_full WHERE address=0x02;
> BEGIN TRANSACTION
> INSERT INTO probe_2ffad4464d834130.transport_full
> (address,payload) VALUES (0x03,0x1122);
> COMMIT TRANSACTION;
> SELECT address, payload, ttl(payload) AS remaining_ttl,
> writetime(payload) AS write_micros
> FROM probe_2ffad4464d834130.transport_full WHERE address=0x03;
> ```
> *Expected result*
> Both rows should be readable immediately after their successful write
> responses,
> with payload `0x1122` and TTL close to 7200 seconds. The transaction form
> should
> not cause a two-hour table TTL to make the new row immediately invisible.
> *Actual result*
> The zero-row SELECT completed {*}{{*}}7 ms{{*}}{*} after the transaction
> response. This is
> not a two-hour expiry-boundary test. An earlier attempt in the same server
> lifetime also showed this ordinary/transaction difference.
> *Possible investigation lead — not a claimed upstream diagnosis*
> Review of the exact Alpha 2 source and an isolated original-JAR value probe
> suggests that fully bound transaction updates construct expiring
> cells/liveness
> with zero time, then replace write timestamps without rebasing local
> expiration.
> Reference-derived values appear to use execution-time parameters. The relevant
> paths are `ModificationStatement.getTxnUpdate`, `TxnWrite` fragment
> completion /
> timestamp replacement, and `AccordUpdateParameters`.
> Potentially related: [CASSANDRA-21376 — Accord: deterministic time
> integration](https://issues.apache.org/jira/browse/CASSANDRA-21376).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
