Madhu Sasidhar created CASSANDRA-21728:
------------------------------------------
Summary: 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
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]
