Investigate whether OCC implementation is unexpectedly checking locks during @WriteLock methods rather than delaying to commit time

// gonna confess here, I am using two containers as I thought it might separate better but I don't actually think this is required to use the two containers to get the separation as the two transactions should I create should be doing that?
       Container<Atomic> theContainer1 = new Container<Atomic>();
       Container<Atomic> theContainer2 = new Container<Atomic>();

       // Setting up the two references to the STM object
       final Atomic obj1 = theContainer1.create(new ExampleSTM());
       final Atomic obj2 = theContainer2.clone(new ExampleSTM(), obj1);

       // Creating a transaction and calling the @WriteLock method set() on it but don't commit the tx
       AtomicAction a = new AtomicAction();
       a.begin();
       obj1.set(1234); // Don't commit this yet - I want to check that a conflicting set() doesn't get the lockexception until commit()

       // Setting up a second independent transaction and calling the @WriteLock method set() on it again
       AtomicAction.suspend();
       AtomicAction b = new AtomicAction();
       b.begin();
       // Now, in my understanding calling this method should only throw a LockException for pessimistic locking, but with the current implementation the Lock throws a conflict now
       obj2.set(12345); // This throws an exception even for @Optimisitic

       // the rest of the test commits the two txs, but IMO as I am using @Optimistic I should not have got the LockException on the second set() so the test failed