[jbossts-issues] [JBoss JIRA] (JBTM-2396) Investigate whether OCC implementation is unexpectedly checking locks during @WriteLock methods rather than delaying to commit time

Mark Little (JIRA) issues at jboss.org
Sun May 10 10:04:19 EDT 2015

     [ https://issues.jboss.org/browse/JBTM-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Little closed JBTM-2396.
    Resolution: Done

> Investigate whether OCC implementation is unexpectedly checking locks during @WriteLock methods rather than delaying to commit time
> -----------------------------------------------------------------------------------------------------------------------------------
>                 Key: JBTM-2396
>                 URL: https://issues.jboss.org/browse/JBTM-2396
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: STM
>            Reporter: Tom Jenkinson
>            Assignee: Mark Little
>         Attachments: OptimisticLockUnitTest.java
> While checking out the STM work I tried to observe the difference between the OCC and PCC variants of the framework. During my testing I was not able to distinguish a difference between the two implementations.
> Consider the following test:
> {code}
> // 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 
> {code}
> Whether the Atomic interface is annotated with either @Optimisitic (or ommitted/default @Pessimisitc) the second @WriteLock set(int) call results in a lockexception being thrown. This is contrary to my expectations for OCC where I would expect to observe the set() being allowed but validation to be performed during commit and the commit to fail.
> From my reading of  STM/src/main/java/org/jboss/stm/internal/reflect/InvocationHandler.java I can see that this class (nor any of the other main classes) uses the OptimisticLock (which appears to suppress lock conflicts). I can see it uses OptimisticLockRecord which may do the validation correctly but my test fails because the second set(int) is allowed.

This message was sent by Atlassian JIRA

More information about the jbossts-issues mailing list