[jbossts-issues] [JBoss JIRA] (JBTM-2396) Investigate whether OCC implementation is unexpectedly checking locks during @WriteLock methods rather than delaying to commit time
Tom Jenkinson (JIRA)
issues at jboss.org
Fri May 8 06:02:45 EDT 2015
Tom Jenkinson created JBTM-2396:
Summary: Investigate whether OCC implementation is unexpectedly checking locks during @WriteLock methods rather than delaying to commit time
Project: JBoss Transaction Manager
Issue Type: Task
Reporter: Tom Jenkinson
Assignee: Mark Little
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:
// 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();
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 b = new AtomicAction();
// 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
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