September 2013 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1040) IL: An apparent infinite recursive loop (IL_INFINITE_RECURSIVE_LOOP)

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1040?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reassigned JBTM-1040: ----------------------------------- Assignee: Tom Jenkinson (was: Paul Robinson) > IL: An apparent infinite recursive loop (IL_INFINITE_RECURSIVE_LOOP) > -------------------------------------------------------------------- > > Key: JBTM-1040 > URL: https://issues.jboss.org/browse/JBTM-1040 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: XTS > Reporter: Amos Feng > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.0.0.M5 > > > 1.XTS/WSAS > com.arjuna.mw.wsas.completionstatus.Unknown Line 52 > There is an apparent infinite recursive loop in com.arjuna.mw.wsas.completionstatus.Unknown.equals(Object) -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-529) Provide a way to disable connection pooling within a transaction

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-529?page=com.atlassian.jira.plugin.s... ] Tom Jenkinson updated JBTM-529: ------------------------------- Fix Version/s: 6.0.0.Final (was: 5.0.0.Final) > Provide a way to disable connection pooling within a transaction > ---------------------------------------------------------------- > > Key: JBTM-529 > URL: https://issues.jboss.org/browse/JBTM-529 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Resource Manager > Affects Versions: 4.5.0, 4.6.0 > Environment: JBossJTA + DataSource with connection pooling (i.e.: DBCP) + Spring > Reporter: Mauro Molinari > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 6.0.0.Final > > Attachments: patch.txt > > > Suppose you are using JBossTS within you webapp, configured using Spring. > Suppose you're doing connection pooling over JBossTS: that is, you have your data source with connection pooling managing connections obtained from the TransactionalDriver of JBossJTA. > As of now, com.arjuna.ats.jdbc.TransactionalDriver.connect(String, Properties) is calling com.arjuna.ats.internal.jdbc.ConnectionManager.create(String, Properties) to get a connection. The latter is behaving like this: > - if an "equivalent" connection has been already created, it's not closed and it is associated with the same transaction, return that connection > - otherwise create a new one > In other words, as stated by the comments in ConnectionManager source, this class is pooling connections for the duration of a transaction. > This however this can lead to severe and hard-to-find problems when you're doing your own connection pooling above JBossJTA using a data source like DBCP. These are two scenarios in which problems can occur: > 1) suppose you have two different data sources that are modeling two logically different databases. However, suppose you're configuring both of them to point to the same physical database (that is: same URL, same username, same password) and you're off course using the same dynamic class to drive the TransactionalDriver to the actual JDBC driver. > Suppose transaction 1 (tx1) is started and, within its duration, a connection is asked to data source 1 (ds1) and another connection is asked to data source 2 (ds2). ds1 and ds2 are initially empty, so the request leads to the creation of two new connections, through TransactionalDriver.connect. Therefore, ds1 asks the TransactionalDriver for a new connection (conn1) and the TransactionalDriver asks the ConnectionManager to create it. conn1 is created and put into ds1, then made available to the client code. But also ds2 is requesting a new connection to the TransactionalDriver: this asks the ConnectionManager, which in turns realizes that it has been requested a connection for the same transaction (tx1), for the same URL, username and password and using the same dynamic class... then, instead of creating another connection (conn2), thanks to its pooling algorythm it returns again conn1, which then goes into ds2! Anyway, tx1 terminates without problems, because the physical database is actually the same. > However, after tx1 has terminated and new transactions are created, because conn1 is in both ds1 and ds2, it may happen that ds1 gives away conn1 to be used for a transaction tx2 while ds2 gives away conn1 to be used for another concurrent transaction tx3. Then, during tx2 or tx3 execution the "Checking transaction and found that this connection is already associated with a different transaction!" error occurs. > To work around this problem you could configure each data source to use a different implementation (that is, different class names!) of the dynamic class. However, another problem could still happen. > 2) suppose you work around problem 1) by using a different dynamic class implementation for each data source. Now, suppose tx4 is started and, during its execution, a thread requests two different connections to ds1. Because of the pooling done by ConnectionManager, it may happen that ds1 receives conn1 twice from the TransactionalDriver, while thinking to receive two DIFFERENT connections. Now, suppose that the data source implementation can handle that without corrupting its internal data structures (and, based on my experiences with DBCP, I wouldn't bet on this!), however this causes conn1 to appear twice in ds1. Then, if tx5 and tx6 are two new concurrent transactions during which requests to ds1 are made, it can happen that conn1 is given to be used in both tx5 and tx6, producing again the already mentioned error. > So, my request is to support a configuration like the one I described by adding the ability to disable connection pooling at transaction level completely. > I'm attaching a suggested patch that provides this functionality by: > - adding support for a connection property named POOL_CONNECTIONS_WITHIN_TRANSACTION wich is assumed to be "true" by default but that can be set to "false" as needed > - changing ConnectionManager.create(String, Properties) to honour that property: if it is set to "false", pooling is disabled and a new connection is always created -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1917) XTS*RecoveryManager.getRecoveryManager() can return null if application deployed before XTS starts

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1917?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1917: -------------------------------- Fix Version/s: 5.0.0.M5 (was: 5.0.0.Final) > XTS*RecoveryManager.getRecoveryManager() can return null if application deployed before XTS starts > -------------------------------------------------------------------------------------------------- > > Key: JBTM-1917 > URL: https://issues.jboss.org/browse/JBTM-1917 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: XTS > Reporter: Paul Robinson > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.0.0.M5 > > > The problem is that there is currently no way of specifying that an application depends on XTS. Therefore it's possible that when the server starts, that the application can be deployed before XTS is started, thus a call to XTSBARecoveryManager.getRecoveryManager() or XTSATRecoveryManager.getRecoveryManager() will return null. > The workaround is to poll for the RecoveryManager until it is not null. > The fix is to have the RecoveryManager injected into the application via a Deployment Unit Processor that has a dependency on the XTS service. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1036) NP: Possible null pointer dereference (NP_NULL_ON_SOME_PATH)

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1036?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1036: -------------------------------- Fix Version/s: 5.0.0.M5 (was: 5.0.0.Final) > NP: Possible null pointer dereference (NP_NULL_ON_SOME_PATH) > ------------------------------------------------------------ > > Key: JBTM-1036 > URL: https://issues.jboss.org/browse/JBTM-1036 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTA, JTS, Transaction Core > Reporter: Amos Feng > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.0.0.M5 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > 1.ArjunaJTA/jdbc > Possible null pointer dereference of conn in com.arjuna.ats.internal.jdbc.recovery.BasicXARecovery.getXAResource() Line 169 > 2.ArjunaCore/arjuna > com.arjuna.ats.arjuna.StateManager Line 1234 > Possible null pointer dereference of action in com.arjuna.ats.arjuna.StateManager.forgetAction(BasicAction, boolean, int) > 3.ArjunaCore/arjuna > com.arjuna.ats.internal.arjuna.objectstore.HashedStore Line 131 > Possible null pointer dereference of aUid in com.arjuna.ats.internal.arjuna.objectstore.HashedStore.allObjUids(String, InputObjectState, int) > 4.ArjunaJTS/jtax > com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.coordinator.ServerTransaction Line 108 > Possible null pointer dereference of ServerTransaction._theXid in com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.coordinator.ServerTransaction.save_state(OutputObjectState, int) > 5.ArjunaJTS/jts > com.arjuna.ats.internal.jts.context.ContextManager Line 553 > Possible null pointer dereference of action in com.arjuna.ats.internal.jts.context.ContextManager.pushAction(ControlWrapper) > 6.ArjunaJTS/jts > com.arjuna.ats.jts.extensions.AtomicTransaction Line 617 > Possible null pointer dereference of AtomicTransaction._theAction in com.arjuna.ats.jts.extensions.AtomicTransaction.equals(Object) -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1856) Provide a transactional driver quickstart

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1856?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1856: -------------------------------- Fix Version/s: 5.0.0.Final (was: 5.0.0.M5) > Provide a transactional driver quickstart > ----------------------------------------- > > Key: JBTM-1856 > URL: https://issues.jboss.org/browse/JBTM-1856 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Demonstrator > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.0.0.Final > > > Provide a simple example of a standalone application using Narayana with Transactional Driver. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1873) Create quickstart showing new features implemented with @Compensatable

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1873?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1873: -------------------------------- Fix Version/s: 5.0.0.Final (was: 5.0.0.M5) > Create quickstart showing new features implemented with @Compensatable > ---------------------------------------------------------------------- > > Key: JBTM-1873 > URL: https://issues.jboss.org/browse/JBTM-1873 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Demonstrator, TXFramework, XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.0.0.Final > > Original Estimate: 4 hours > Time Spent: 3 hours > Remaining Estimate: 1 hour > > Show main features provided by @Compensatable annotation: dontCancelOn, cancelOn, compensation types. > Reuse Paul's quickstart JBTM-1682. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1930) Document transaction subsystem CLI

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1930?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-1930: ------------------------------------- Thanks Ondra, that looks like what I was missing. Mike is there any chance we can back port this into our community docs please? > Document transaction subsystem CLI > ---------------------------------- > > Key: JBTM-1930 > URL: https://issues.jboss.org/browse/JBTM-1930 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.0.0.Final > > > I certainly couldn't find it by grepping our XML for the method I knew that should exist "probe". -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1930) Document transaction subsystem CLI

by Ondřej Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-1930?page=com.atlassian.jira.plugin.... ] Ondřej Chaloupka commented on JBTM-1930: ---------------------------------------- Quite good CLI documentation could be found under EAP documentation at http://documentation-devel.engineering.redhat.com/docs/en-US/JBoss_Enterp... > Document transaction subsystem CLI > ---------------------------------- > > Key: JBTM-1930 > URL: https://issues.jboss.org/browse/JBTM-1930 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.0.0.Final > > > I certainly couldn't find it by grepping our XML for the method I knew that should exist "probe". -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1930) Document transaction subsystem CLI

by Tom Jenkinson (JIRA)

Tom Jenkinson created JBTM-1930: ----------------------------------- Summary: Document transaction subsystem CLI Key: JBTM-1930 URL: https://issues.jboss.org/browse/JBTM-1930 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Documentation Reporter: Tom Jenkinson Assignee: Michael Musgrove Fix For: 5.0.0.Final I certainly couldn't find it by grepping our XML for the method I knew that should exist "probe". -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1929) Enhancement to TxProf to handle updated logging added in JBTM-1915

by Alex Creasy (JIRA)

[ https://issues.jboss.org/browse/JBTM-1929?page=com.atlassian.jira.plugin.... ] Alex Creasy updated JBTM-1929: ------------------------------ Summary: Enhancement to TxProf to handle updated logging added in JBTM-1915 (was: Enhancement to handle updated logging added in JBTM-1915) > Enhancement to TxProf to handle updated logging added in JBTM-1915 > ------------------------------------------------------------------ > > Key: JBTM-1929 > URL: https://issues.jboss.org/browse/JBTM-1929 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: TxProf > Reporter: Alex Creasy > Assignee: Paul Robinson > > A modification to the regex in TxFinalStatusHandler is required to handle the logging changes made to Narayana described in https://issues.jboss.org/browse/JBTM-1915. -- 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

11 years, 2 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 September 2013