[JBoss JIRA] (JBTM-2400) Add logging to help clarify if a TX is rolling back due to OCC conflict
by Tom Jenkinson (JIRA)
Tom Jenkinson created JBTM-2400:
-----------------------------------
Summary: Add logging to help clarify if a TX is rolling back due to OCC conflict
Key: JBTM-2400
URL: https://issues.jboss.org/browse/JBTM-2400
Project: JBoss Transaction Manager
Issue Type: Feature Request
Components: STM
Reporter: Tom Jenkinson
Assignee: Mark Little
Currently if a transaction including an STM object aborts due to an OCC violation then nothing is logged to assist a user with understanding the reason for the rollback.
I am wondering whether this should be a TRACE or even WARN to match what would happen with other (say XA) resource managers.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (JBTM-1732) Durable STM instances require explicit sync to save state
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-1732?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-1732:
-----------------------------------
Adding for completeness: the workaround (as with TXOJ) is to force write the state prior to any other users (threads, cloned instances or processes) using the object.
> Durable STM instances require explicit sync to save state
> ---------------------------------------------------------
>
> Key: JBTM-1732
> URL: https://issues.jboss.org/browse/JBTM-1732
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: STM
> Affects Versions: 5.0.0.M3
> Reporter: Mark Little
> Assignee: Mark Little
> Priority: Optional
>
> As with TXOJ, a persistent STM object isn't written to disk until a write lock is acquired on it within the scope of a transaction. Consider automating this at creation time.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (JBTM-2396) Investigate whether OCC implementation is unexpectedly checking locks during @WriteLock methods rather than delaying to commit time
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-2396?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-2396:
-----------------------------------
If you add a JIRA I'll take a look :)
> 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
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (JBTM-2396) Investigate whether OCC implementation is unexpectedly checking locks during @WriteLock methods rather than delaying to commit time
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2396?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2396:
-------------------------------------
I see the test passing now - thanks for the quick update :)
re the LockException misconception I had, I now understand why throwing an exception is wrong here, though I wonder if it is worth trace logging something to help clarify if a TX is rolling back due to OCC conflict?
> 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
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (JBTM-2396) Investigate whether OCC implementation is unexpectedly checking locks during @WriteLock methods rather than delaying to commit time
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-2396?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-2396:
-----------------------------------
Forgot to mention that the test had a comment about how commit should throw a LockException. That's not right. We only force the transaction to rollback if a conflict is detected at commit time.
Then the test state that was assumed (1234) was also wrong, since the first transaction to commit actually makes the state 12345.
I changed the test for both of these.
> 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
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (JBTM-2396) Investigate whether OCC implementation is unexpectedly checking locks during @WriteLock methods rather than delaying to commit time
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-2396?page=com.atlassian.jira.plugin.... ]
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
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (JBTM-2396) Investigate whether OCC implementation is unexpectedly checking locks during @WriteLock methods rather than delaying to commit time
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-2396?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-2396:
-----------------------------------
There were a few things at work here.
(i) the test used a couple of containers and cloned the object. That's legal but it exposed a bug in the way in which locks were saved and restored. They were created (in the first container) as OptimisticLock but restored (in the second container) as Lock which caused conflicts. That's fixed now but I may revisit the fix. See https://issues.jboss.org/browse/JBTM-2399 for more details.
(ii) the OptimisticLock wasn't created by InvocationHandler, as you mentioned.
(iii) because the test uses two containers and object invocations happen before any initial state has been saved for the instance, the activate for the copy fails - there's no state to load. This is a known issue (https://issues.jboss.org/browse/JBTM-1732). I changed the test to work around it for now.
> 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
(v6.3.15#6346)
9 years, 1 month