[ 
https://issues.apache.org/jira/browse/CASSANDRA-18937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Henrik Ingo updated CASSANDRA-18937:
------------------------------------
    Resolution: Invalid
        Status: Resolved  (was: Triage Needed)

Closing: Bug was in code added by myself.

> 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
>            Priority: Normal
>
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to