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]

Reply via email to