Commit Exception on the second commit after thread interruption

[Sat-Ing]

Reproducible with CDO Version 4.23.0.
If an interrupted thread makes changes to the model, then we can run into the following problem.
I can only reliably reproduce this problem when using a CDOMergingConflictResolver. But I think that it also happened (rarely) if no conflict resolver was in place.

Steps to reproduce the problem (also check code below)

• Open an object in a transaction
• Modify the object in a thread which is interrupted (which throws an exception, which is fine)
• Commit the transaction in the original thread => everything looks good, also the value is correct
• Modify the object again and commit it => Unexpected commit exception: "Attempt by Transaction[2:1] to modify historical revisions: (...)"

It can be reproduced with the following code:

  public void testCase() throws Exception
  {
    CDOSession session = openSession();
    CDOTransaction transaction = session.openTransaction();
    transaction.options().addConflictResolver(new CDOMergingConflictResolver());

    OrderDetail orderDetail = getModel1Factory().createOrderDetail();
    orderDetail.setPrice(1);
    CDOResource resource = transaction.createResource(getResourcePath("/test1"));
    resource.getContents().add(orderDetail);

    transaction.commit();

    Thread t = new Thread(() -> {
      Thread.currentThread().interrupt();
      orderDetail.setPrice(2);
    });
    t.start();
    t.join();

    transaction.commit();
    orderDetail.setPrice(3);
    transaction.commit(); // <<<< exception
  }

[estepper]

Thanks for the test case! I'm currently on travel and can't look at this before next week...

[estepper]

I'm playing with your test case and I can reproduce the effect you've described. I also understand what's going on, but I'm not sure whether it's a bug. In the end your thread t calls methods on the shared transaction (through orderDetail) and one of these methods exits with an exception, leaving the transaction in a bad state. The following snippet demonstrates how to deal with this bad state:

      Thread t = new Thread(() -> {
        try
        {
          Thread.currentThread().interrupt();
          orderDetail.setPrice(2);
        }
        catch (Throwable ex)
        {
          ex.printStackTrace();

          Thread.interrupted();
          transaction.rollback();
        }
      });
      t.start();
      t.join();

With this code your test case succeeds. What do you think?

[Sat-Ing]

Yes, I think that this is the way that this problem should be handled currently.
But in case that the transaction is not rolled back: could we have a commit exception on the first commit? In our case the problem was quite hard to track down because of this.