Henrik Ingo created CASSANDRA-18937:
---------------------------------------
Summary: Two accord transactions have the exact same transaction id
Key: CASSANDRA-18937
URL: https://issues.apache.org/jira/browse/CASSANDRA-18937
Project: Cassandra
Issue Type: Bug
Components: Accord
Reporter: Henrik Ingo
When testing solutions for CASSANDRA-18798 I noticed that two independent
transactions running at the same time in two parallel threads ended up having
the exact same transaction id:
{code}
public void testListAddition() throws Exception
{
SHARED_CLUSTER.schemaChange("CREATE TABLE " + currentTable + " (k int
PRIMARY KEY, l list<int>)");
SHARED_CLUSTER.forEach(node -> node.runOnInstance(() ->
AccordService.instance().setCacheSize(0)));
CountDownLatch latch = CountDownLatch.newCountDownLatch(1);
Vector<Integer> completionOrder = new Vector<>();
try
{
for (int i=0; i<100; i++)
{
ForkJoinTask<?> add1 = ForkJoinPool.commonPool().submit(() -> {
latch.awaitThrowUncheckedOnInterrupt();
SHARED_CLUSTER.get(1).executeInternal("BEGIN TRANSACTION " +
"UPDATE " + currentTable + " SET l = l + [1] WHERE
k = 1; " +
"COMMIT TRANSACTION");
completionOrder.add(1);
});
ForkJoinTask<?> add2 = ForkJoinPool.commonPool().submit(() -> {
try {
Thread.sleep(0);
{code}
Adding some logging in TxnWrite.java reveals the two threads ave identical
executeAt and unix timestamps:
{noformat}
lastmicros 0
DEBUG [node2_Messaging-EventLoop-3-4] node2 2023-10-18 18:26:08,954
AccordVerbHandler.java:54 - Receiving Apply{kind:Minimal,
txnId:[10,1697642767659000,10,1], deps:[distributed_test_keyspace:[(-Inf,-1],
(-1,9223372036854775805], (9223372036854775805,+Inf]]]:{}, {},
executeAt:[10,1697642767659000,10,1],
writes:TxnWrites{executeAt:[10,1697642767659000,10,1],
keys:[distributed_test_keyspace:DecoratedKey(-4069959284402364209, 00000001)],
write:TxnWrite{}}, result:accord.api.Result$1@253c102e} from /127.0.0.1:7012
raw 0 (NO_LAST_EXECUTED_HLC=-9223372036854775808
lastExecutedTimestamp [0,0,0,0]
lastmicros 1697642767659000
raw -9223372036854775808 (NO_LAST_EXECUTED_HLC=-9223372036854775808
lastExecutedTimestamp [10,1697642767659000,10,1]
DEBUG [node2_CommandStore[1]:1] node2 2023-10-18 18:26:09,023
AccordMessageSink.java:167 - Replying ACCORD_APPLY_RSP ApplyApplied to
/127.0.0.1:7012
lastmicros 0
raw 0 (NO_LAST_EXECUTED_HLC=-9223372036854775808
lastExecutedTimestamp [0,0,0,0]
lastmicros 1697642767659000
raw -9223372036854775808 (NO_LAST_EXECUTED_HLC=-9223372036854775808
lastExecutedTimestamp [10,1697642767659000,10,1]
timestamp 1697642767659000 executeAt[10,1697642767659000,10,1]
timestamp 1697642767659000 executeAt[10,1697642767659000,10,1]
{noformat}
Increasing the Thread.sleep() to9 or 10 helps so that the transactions have
different IDs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]