May 2015 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2399) Consider adding optimistic write/read to LockMode and removing OptimisticLock

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBTM-2399?page=com.atlassian.jira.plugin.... ] Mark Little commented on JBTM-2399: ----------------------------------- If this is done then revert change to loadState in LockManager. See comment in code. > Consider adding optimistic write/read to LockMode and removing OptimisticLock > ----------------------------------------------------------------------------- > > Key: JBTM-2399 > URL: https://issues.jboss.org/browse/JBTM-2399 > Project: JBoss Transaction Manager > Issue Type: Task > Components: STM > Affects Versions: 5.1.1 > Reporter: Mark Little > Assignee: Mark Little > > Would help simplify some of the OptimisticLockManager code duplication. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2399) Consider adding optimistic write/read to LockMode and removing OptimisticLock

by Mark Little (JIRA)

Mark Little created JBTM-2399: --------------------------------- Summary: Consider adding optimistic write/read to LockMode and removing OptimisticLock Key: JBTM-2399 URL: https://issues.jboss.org/browse/JBTM-2399 Project: JBoss Transaction Manager Issue Type: Task Components: STM Affects Versions: 5.1.1 Reporter: Mark Little Assignee: Mark Little Would help simplify some of the OptimisticLockManager code duplication. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 1 month

1
0
0 / 0

[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: ----------------------------------- You're right - for some reason the only use of OptimisticLock is within the actual tests. I'll take a look at this further when I get a chance. Will add your test too. > 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

1
0
0 / 0

[JBoss JIRA] (JBTM-2398) Support VolatileStore.allObjUids

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBTM-2398?page=com.atlassian.jira.plugin.... ] Mark Little commented on JBTM-2398: ----------------------------------- If you add it to VolatileStore then may as well also add it to TwoPhaseVolatileStore. > Support VolatileStore.allObjUids > --------------------------------- > > Key: JBTM-2398 > URL: https://issues.jboss.org/browse/JBTM-2398 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Performance Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.later > > > This method is used by REST-AT and would be a useful addition for baselining the performance of the coordinator for comparison with non transactional and empty transaction requests. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2390) port the RTS test org.jboss.jbossts.star.test.PerformanceTest to a benchmark

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2390?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2390: ----------------------------------- Comment: was deleted (was: Changes pushed to the performance repo) > port the RTS test org.jboss.jbossts.star.test.PerformanceTest to a benchmark > ---------------------------------------------------------------------------- > > Key: JBTM-2390 > URL: https://issues.jboss.org/browse/JBTM-2390 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > Currently this test is run on an ad hoc basis on the NCL cluster. I would like it moved into the benchmark suite for more regular testing. > I have started work on this task but am finding threads deadlocking which has delayed the port. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2390) port the RTS test org.jboss.jbossts.star.test.PerformanceTest to a benchmark

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2390?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2390: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Changes pushed to the performance repo > port the RTS test org.jboss.jbossts.star.test.PerformanceTest to a benchmark > ---------------------------------------------------------------------------- > > Key: JBTM-2390 > URL: https://issues.jboss.org/browse/JBTM-2390 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > Currently this test is run on an ad hoc basis on the NCL cluster. I would like it moved into the benchmark suite for more regular testing. > I have started work on this task but am finding threads deadlocking which has delayed the port. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2390) port the RTS test org.jboss.jbossts.star.test.PerformanceTest to a benchmark

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2390?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-2390: ---------------------------------------- I agree since the volatile store is handy for providing a baseline > port the RTS test org.jboss.jbossts.star.test.PerformanceTest to a benchmark > ---------------------------------------------------------------------------- > > Key: JBTM-2390 > URL: https://issues.jboss.org/browse/JBTM-2390 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > Currently this test is run on an ad hoc basis on the NCL cluster. I would like it moved into the benchmark suite for more regular testing. > I have started work on this task but am finding threads deadlocking which has delayed the port. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2398) Support VolatileStore.allObjUids

by Michael Musgrove (JIRA)

Michael Musgrove created JBTM-2398: -------------------------------------- Summary: Support VolatileStore.allObjUids Key: JBTM-2398 URL: https://issues.jboss.org/browse/JBTM-2398 Project: JBoss Transaction Manager Issue Type: Feature Request Components: Performance Testing Affects Versions: 5.1.1 Reporter: Michael Musgrove Assignee: Michael Musgrove Priority: Optional Fix For: 5.later This method is used by REST-AT and would be a useful addition for baselining the performance of the coordinator for comparison with non transactional and empty transaction requests. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2390) port the RTS test org.jboss.jbossts.star.test.PerformanceTest to a benchmark

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2390?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2390: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/performance/pull/14 > port the RTS test org.jboss.jbossts.star.test.PerformanceTest to a benchmark > ---------------------------------------------------------------------------- > > Key: JBTM-2390 > URL: https://issues.jboss.org/browse/JBTM-2390 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > Currently this test is run on an ad hoc basis on the NCL cluster. I would like it moved into the benchmark suite for more regular testing. > I have started work on this task but am finding threads deadlocking which has delayed the port. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2390) port the RTS test org.jboss.jbossts.star.test.PerformanceTest to a benchmark

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2390?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-2390: ------------------------------------- Maybe we should Jira to add that, it would just be a hashmap or something so shouldn't add much and might be more useful then. Just an idea. > port the RTS test org.jboss.jbossts.star.test.PerformanceTest to a benchmark > ---------------------------------------------------------------------------- > > Key: JBTM-2390 > URL: https://issues.jboss.org/browse/JBTM-2390 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > Currently this test is run on an ad hoc basis on the NCL cluster. I would like it moved into the benchmark suite for more regular testing. > I have started work on this task but am finding threads deadlocking which has delayed the port. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues May 2015