October 2013 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1970) SPI additions for enlisting XA resources

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBTM-1970?page=com.atlassian.jira.plugin.... ] Jesper Pedersen commented on JBTM-1970: --------------------------------------- I'll do a release once the new SPI is ready. Ideally there should be a Narayana release that supports the two new interfaces, but that can be included later, as the focus currently is to deliver an IJ release to WildFly > SPI additions for enlisting XA resources > ---------------------------------------- > > Key: JBTM-1970 > URL: https://issues.jboss.org/browse/JBTM-1970 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: SPI > Affects Versions: 5.0.0.M5 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.0.Final > > > Two additional items are required: > * org.jboss.tm.ConnectableLastResource shouldn't extend LastResource in order to make it a mix-in interface that can be used for XA resources too; > * promotion of com.arjuna.ats.jta.resources.StartXAResource to the SPI. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1938) Caching of datasource for JDBC store incompatible with WildFly :reload operation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-1938?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-1938: ----------------------------------------------- Ondrej Chaloupka <ochaloup(a)redhat.com> changed the Status of [bug 1009931|https://bugzilla.redhat.com/show_bug.cgi?id=1009931] from ASSIGNED to ON_QA > Caching of datasource for JDBC store incompatible with WildFly :reload operation > -------------------------------------------------------------------------------- > > Key: JBTM-1938 > URL: https://issues.jboss.org/browse/JBTM-1938 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Recovery > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.11, 5.0.0.M5 > > > The JDBC object store makes a performance optimization to cache the datasource it obtains connections from. Unfortunately this is not compatible with WildFly :reload (see linked bugzilla for stack trace). > Without further performance constraints I have moved to obtaining a reference each time. If there are performance issues we might need to provide a way for the subsystem to invalidate the cached reference when :reload is called. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1938) Caching of datasource for JDBC store incompatible with WildFly :reload operation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-1938?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-1938: ----------------------------------------------- Ondrej Chaloupka <ochaloup(a)redhat.com> made a comment on [bug 1009931|https://bugzilla.redhat.com/show_bug.cgi?id=1009931] Hi Tom, I agree this is different issue which is related to module dependency management in AS rather than to transactions subsystem. Just to clarify the problem happens to me just after the reload. I didn't experience the problem after the initial load. But it could be a coincidence. I will report this problem as a new bz and I will verify this one. Thanks Ondra > Caching of datasource for JDBC store incompatible with WildFly :reload operation > -------------------------------------------------------------------------------- > > Key: JBTM-1938 > URL: https://issues.jboss.org/browse/JBTM-1938 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Recovery > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.11, 5.0.0.M5 > > > The JDBC object store makes a performance optimization to cache the datasource it obtains connections from. Unfortunately this is not compatible with WildFly :reload (see linked bugzilla for stack trace). > Without further performance constraints I have moved to obtaining a reference each time. If there are performance issues we might need to provide a way for the subsystem to invalidate the cached reference when :reload is called. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1970) SPI additions for enlisting XA resources

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1970?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-1970: ---------------------------------------- When do yo want to release 1.1.1? > SPI additions for enlisting XA resources > ---------------------------------------- > > Key: JBTM-1970 > URL: https://issues.jboss.org/browse/JBTM-1970 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: SPI > Affects Versions: 5.0.0.M5 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.0.Final > > > Two additional items are required: > * org.jboss.tm.ConnectableLastResource shouldn't extend LastResource in order to make it a mix-in interface that can be used for XA resources too; > * promotion of com.arjuna.ats.jta.resources.StartXAResource to the SPI. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1989) Uid comparison fails for max uid

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1989?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-1989: ----------------------------------- Fix Version/s: (was: 4.17.14) > Uid comparison fails for max uid > -------------------------------- > > Key: JBTM-1989 > URL: https://issues.jboss.org/browse/JBTM-1989 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Common > Affects Versions: 5.0.0.M6 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.0.Final > > > The largest Uid (Uid.MAX_UID) is defined to have the string form 7fffffff:7fffffff:7fffffff:7fffffff:7fffffff > The first 2 components are hex values corresponding to Integer.MAX_INT but these two fields end up being converted into 2 longs to populate the field long[] hostAddr hostAddr. Consequently most Uids will end up being greater than MAX_UID (which causes problems when trying to order last resources last in the intentions list. > The fix is to use "7fffffffffffffff:7fffffffffffffff:7fffffff:7fffffff:7fffffff" for MAX_UID -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1938) Caching of datasource for JDBC store incompatible with WildFly :reload operation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-1938?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-1938: ----------------------------------------------- tom.jenkinson(a)redhat.com made a comment on [bug 1009931|https://bugzilla.redhat.com/show_bug.cgi?id=1009931] Hi Ondra, I think it is a different cause. The last issue was that the JDBC object store caches connections, this new issue seems to be related to there not being a dependency between the TM and JCA services (i.e. from a BZ point of view, this new issue could affect the initial load, not just a :reload)? I will look further... Tom > Caching of datasource for JDBC store incompatible with WildFly :reload operation > -------------------------------------------------------------------------------- > > Key: JBTM-1938 > URL: https://issues.jboss.org/browse/JBTM-1938 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Recovery > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.11, 5.0.0.M5 > > > The JDBC object store makes a performance optimization to cache the datasource it obtains connections from. Unfortunately this is not compatible with WildFly :reload (see linked bugzilla for stack trace). > Without further performance constraints I have moved to obtaining a reference each time. If there are performance issues we might need to provide a way for the subsystem to invalidate the cached reference when :reload is called. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1968) Add possibility to parametrize qa jts tests running with JDBC Object Store

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1968?page=com.atlassian.jira.plugin.... ] Tom Jenkinson resolved JBTM-1968. --------------------------------- Resolution: Done > Add possibility to parametrize qa jts tests running with JDBC Object Store > -------------------------------------------------------------------------- > > Key: JBTM-1968 > URL: https://issues.jboss.org/browse/JBTM-1968 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Testing > Affects Versions: 4.17.10 > Reporter: Ondřej Chaloupka > Assignee: Ondřej Chaloupka > Fix For: 4.17.14, 5.0.0.Final > > > Current ant configuration is hardcoded and there is no possibility to parametrize db properties to get test running against different databases. > Rework the qa/run-tests.xml file to add such functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1989) Uid comparison fails for max uid

by Michael Musgrove (JIRA)

Michael Musgrove created JBTM-1989: -------------------------------------- Summary: Uid comparison fails for max uid Key: JBTM-1989 URL: https://issues.jboss.org/browse/JBTM-1989 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Common Affects Versions: 5.0.0.M6 Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 4.17.14, 5.0.0.Final The largest Uid (Uid.MAX_UID) is defined to have the string form 7fffffff:7fffffff:7fffffff:7fffffff:7fffffff The first 2 components are hex values corresponding to Integer.MAX_INT but these two fields end up being converted into 2 longs to populate the field long[] hostAddr hostAddr. Consequently most Uids will end up being greater than MAX_UID (which causes problems when trying to order last resources last in the intentions list. The fix is to use "7fffffffffffffff:7fffffffffffffff:7fffffff:7fffffff:7fffffff" for MAX_UID -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1970) SPI additions for enlisting XA resources

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1970?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-1970: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/jboss-transaction-spi/pull/4 > SPI additions for enlisting XA resources > ---------------------------------------- > > Key: JBTM-1970 > URL: https://issues.jboss.org/browse/JBTM-1970 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: SPI > Affects Versions: 5.0.0.M5 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.0.Final > > > Two additional items are required: > * org.jboss.tm.ConnectableLastResource shouldn't extend LastResource in order to make it a mix-in interface that can be used for XA resources too; > * promotion of com.arjuna.ats.jta.resources.StartXAResource to the SPI. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1988) Downgrade certain log messages when we end a branch using TMFAIL

by Tom Jenkinson (JIRA)

Tom Jenkinson created JBTM-1988: ----------------------------------- Summary: Downgrade certain log messages when we end a branch using TMFAIL Key: JBTM-1988 URL: https://issues.jboss.org/browse/JBTM-1988 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JTA, Resource Manager Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.0.0.Final JBTM-1786 changed the XAResourceRecord::topLevelAbort such that the flag we send to XAR::end() from TMSUCCESS to TMFAIL. It is possible that when we call XAResource::end(TMFAIL) the branch may have been: 1. marked as rollback only 2. rolled back >From the XA spec: "The portion of work has failed. A resource manager might choose to mark a transaction branch as rollback-only at this point. In fact, a transaction manager does so for the global transaction. If a resource manager chooses to do so also, xa_end() returns one of the [XA_RB∗] values. TMFAIL cannot be used in conjunction with either TMSUSPEND or TMSUCCESS." We cannot rely on the resource manager having rolled back the branch so we have to call XAR::rollback. An example is DB2, in this case it _has_ rolled back the branch and so can raise an XAException when we call rollback on it. We should record if the RM has returned an XA_RBROLLBACK during end and if the RM then returns XAER_RMFAIL during rollback we should downgrade the logging to debug level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 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 October 2013