July 2014 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2183) Need finer grained control over which XAResource is used for recovery

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2183?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-2183: ----------------------------------------------- Ondrej Chaloupka <ochaloup(a)redhat.com> changed the Status of [bug 1075008|https://bugzilla.redhat.com/show_bug.cgi?id=1075008] from NEW to CLOSED > Need finer grained control over which XAResource is used for recovery > --------------------------------------------------------------------- > > Key: JBTM-2183 > URL: https://issues.jboss.org/browse/JBTM-2183 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Recovery > Affects Versions: 4.17.20, 5.0.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.0.3 > > > During recovery when we recreate an XAResource we need one which knows about the xid that is being recovered. We implement this in the XARecoveryModule which calls recover() on each resource returned by registered XA recovery helpers. If the xid returned from recover matches against the one we are recovering we use that XAResource to drive recovery. > However, some RMs will return all prepared transaction branches and not just the ones specific to the particular resource we made the recover call on. The scenario that led to the issue was configuring 2 datasources against the same database but with different credentials. If we replay the commit on the "wrong" one we get ORA-24774: "The transaction specified in the call refers to a transaction created by a different user". > The fix is to return an XA resource that matches the JNDI name we logged in the recovery record and if the JNDI name is not available we drop back to using the current solution (note that the name is available when running in wildfly/EAP) . > And finally, I I wonder if we want to make this new behaviour optional? -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2207) Make default name null in order for quick lookup in BeanPopulator

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2207?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-2207: ------------------------------------- Looking at the diff I would have no objection to merging this, but please can you provide more details in the description of what the performance win is that you are seeing and also a rationale for the reason to make the change so we can audit the modification. For example, it looks from the diff as if the main reason is to avoid a string comparison per lookup of the bean name. I believe we only lookup the beans once during initialization. That being said if there is something else please do let me know. As always, seeing some performance numbers before and after would help too if you have them available. Thanks, Tom > Make default name null in order for quick lookup in BeanPopulator > ----------------------------------------------------------------- > > Key: JBTM-2207 > URL: https://issues.jboss.org/browse/JBTM-2207 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2203) Remove ReentrantLock from StateManager

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2203?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-2203: ------------------------------------- I don't think we can remove the *Mutex() methods from StateManager as these are part of the public API so people that inherit from that class would no longer have access to them (as you saw in the tests you had to modify). Please can you provide a few more details on what the performance win was with removing the Reentrant lock to help evaluate the benefit vs the drawback of the API change? > Remove ReentrantLock from StateManager > -------------------------------------- > > Key: JBTM-2203 > URL: https://issues.jboss.org/browse/JBTM-2203 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: JTA > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.0.3 > > > Remove unused lock from StateManager, and add the access methods to LockManager instead -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2206) Use synchronized HashMaps

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-2206: ---------------------------------------- Most (if not all) of our usages of Hashtable are internal so external users should not be impacted. > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2206) Use synchronized HashMaps

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-2206: ------------------------------------- I don't think we should change ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/CheckedAction.java as it is in the public API so unless it has considerable performance win the cost of update apps to use the new API is probably not justified. As to the rest of the changes, can you give us a brief indication of the performance benefit of this particular change? > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2209) Use Deque for ThreadActionData

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2209?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-2209: ------------------------------------- Hi Jesper, Please can you add a few more details to the Jira on the reasons for the change? Tom > Use Deque for ThreadActionData > ------------------------------ > > Key: JBTM-2209 > URL: https://issues.jboss.org/browse/JBTM-2209 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Note, there are other usages of java.util.Stack in the code base that could be changed as well -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2208) Removed unused method from ActionManager

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2208?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-2208: ------------------------------------- Change to remove effectively dead code looks good to me. > Removed unused method from ActionManager > ---------------------------------------- > > Key: JBTM-2208 > URL: https://issues.jboss.org/browse/JBTM-2208 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Removed unused method from ActionManager, and thereby a System.currentTimeMillis call -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2222) Rename TXFramework -> Compensations

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBTM-2222?page=com.atlassian.jira.plugin.... ] Mark Little commented on JBTM-2222: ----------------------------------- Great. Don't ignore the community, even if they're silent. Or they will ignore you. > Rename TXFramework -> Compensations > ----------------------------------- > > Key: JBTM-2222 > URL: https://issues.jboss.org/browse/JBTM-2222 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: TXFramework > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.3 > > > TXFramework now just focuses on Compensating transactions. The ACID transaction improvements have been moved into XTS and REST components. Therefore, we should drop the TXFramework name in favour of "Compensations" or "Compensating Transactions". -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2222) Rename TXFramework -> Compensations

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2222?page=com.atlassian.jira.plugin.... ] Paul Robinson commented on JBTM-2222: ------------------------------------- I'll create a post shortly, identifying the refactorings that I am proposing. > Rename TXFramework -> Compensations > ----------------------------------- > > Key: JBTM-2222 > URL: https://issues.jboss.org/browse/JBTM-2222 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: TXFramework > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.3 > > > TXFramework now just focuses on Compensating transactions. The ACID transaction improvements have been moved into XTS and REST components. Therefore, we should drop the TXFramework name in favour of "Compensations" or "Compensating Transactions". -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2224) Move Compensations dependency adder to transactions subsytem

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2224?page=com.atlassian.jira.plugin.... ] Paul Robinson commented on JBTM-2224: ------------------------------------- I'll create a post shortly, identifying the refactorings that I am proposing. > Move Compensations dependency adder to transactions subsytem > ------------------------------------------------------------ > > Key: JBTM-2224 > URL: https://issues.jboss.org/browse/JBTM-2224 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Application Server Integration, TXFramework > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.3 > > > The Compensating transactions API can now be used in standalone.xml as well as standalone-xts.xml. XTS is now only needed for distributed compensating transactions. > Therefore, it would be better to move the automatic dependency adding code to the transactions subsystem. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues July 2014