[
https://issues.apache.org/jira/browse/CASSANDRA-21728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Madhu Sasidhar updated CASSANDRA-21728:
---------------------------------------
Description:
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).
was:
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).
#
##
> 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]
