February 2012 - jbossts-issues - Jboss List Archives

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

by Mauro Molinari (JIRA)

Provide a way to disable connection pooling within a transaction ---------------------------------------------------------------- Key: JBTM-529 URL: https://jira.jboss.org/jira/browse/JBTM-529 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Configuration, Documentation, JTA Affects Versions: 4.6.0, 4.5.0 Environment: JBossJTA + DataSource with connection pooling (i.e.: DBCP) + Spring Reporter: Mauro Molinari Priority: Critical 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 contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

4
8
0 / 0

[JBoss JIRA] Created: (JBTM-809) Evaluate JCA replacement for transactional jdbc driver

by Tom Jenkinson (JIRA)

Evaluate JCA replacement for transactional jdbc driver ------------------------------------------------------ Key: JBTM-809 URL: https://jira.jboss.org/browse/JBTM-809 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JCA, JTA Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.0.0 Take a look at this -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

2
7
0 / 0

[JBoss JIRA] (JBTM-953) Remove home-brew SOAP stack from XTS unit tests

by Paul Robinson (Created) (JIRA)

Remove home-brew SOAP stack from XTS unit tests ----------------------------------------------- Key: JBTM-953 URL: https://issues.jboss.org/browse/JBTM-953 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Reporter: Paul Robinson Assignee: Paul Robinson Priority: Minor Fix For: 5.0.0.Final In the past these tests used a mock/simple SOAP stack developed specifically for the tests. This stack is no longer used as the tests run within JBoss AS. This code is redundant and should be removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

4
7
0 / 0

[JBoss JIRA] (JBTM-1007) Review annotation names offered by the TXFramework

by Paul Robinson (Created) (JIRA)

Review annotation names offered by the TXFramework -------------------------------------------------- Key: JBTM-1007 URL: https://issues.jboss.org/browse/JBTM-1007 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: TXFramework Affects Versions: 5.0.0.M1 Reporter: Paul Robinson Assignee: Paul Robinson Fix For: 5.0.0.Final Essentially, we need to ensure that they provide a good description to the user of what they do. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

2
3
0 / 0

[JBoss JIRA] Created: (JBTM-223) Check WL-to-JBossTS interoperability (via JTS).

by Mark Little (JIRA)

Check WL-to-JBossTS interoperability (via JTS). ----------------------------------------------- Key: JBTM-223 URL: http://jira.jboss.com/jira/browse/JBTM-223 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTS Implementation Reporter: Mark Little Assigned To: Mark Little -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

2
4
0 / 0

[JBoss JIRA] (JBTM-981) Annotation support for transaction bridging

by Paul Robinson (Created) (JIRA)

Annotation support for transaction bridging ------------------------------------------- Key: JBTM-981 URL: https://issues.jboss.org/browse/JBTM-981 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Paul Robinson Assignee: Paul Robinson Fix For: 5.0.0.M2 Currently the developer specifies the type of transaction that the service and any lifecycle callbacks expect to participate in. For example, via @WSBA or @RESTJDI class level annotation. However, the participation requirements for these protocols is very similar. It would be better if the developer could simply specify that the service can participate in any forward compensation style transaction (such as REST-JDI or WS-BA) using a @BA annotation. The type of transaction is determined by the inflowed TX context. To take this a step further, by leaving off the transaction type annotation altogether, the service could participate in any transaction type. Of course, this would require a mix of ACID and forward compensation lifecycle callbacks to be present. Again, the inflow TX context would decide the actual TX type used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

3
10
0 / 0

[JBoss JIRA] (JBTM-980) Move to generic participants

by Paul Robinson (Created) (JIRA)

Move to generic participants ---------------------------- Key: JBTM-980 URL: https://issues.jboss.org/browse/JBTM-980 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Paul Robinson Assignee: Paul Robinson Fix For: 5.0.0.M2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

3
5
0 / 0

[JBoss JIRA] Created: (JBTM-649) Support XAException.XA_RETRY in 2 phase commit -- Backward Compatibility issue

by Howard Gao (JIRA)

Support XAException.XA_RETRY in 2 phase commit -- Backward Compatibility issue ------------------------------------------------------------------------------ Key: JBTM-649 URL: https://jira.jboss.org/jira/browse/JBTM-649 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 4.6.1 Reporter: Howard Gao Fix For: 4.6.1.CP04 After upgrading from 4.4.0 to 4.6.1 (release for AS5), one of the JBoss Messaging test starts to fail. The scenario is: 1. We have two XAResources res1 and res2. Both are enlisted in a Transaction. 2. res1 sends a message to Queue1 (server1), res2 sends a message to Queue2 (server2). 3. delist res1 and res2 and commit the transaction. 4. During the commit process, we simulate a failure on res2.commit() so that the res1.prepare(), res2.prepare() and res1.commit() are all successful but res2.commit() will throw XAException.XA_RETRY exception -- eventually leaving the transaction in a Heuristic state. 5. Then we restore res2 back to normal, hoping that the Recovery Manager will kick in and recover the transaction. So we expect that the two sent messages will be received by the receiver. To allow the recovery to happen we give a 60 second timeout to receive the second message. But the result is the first message is received but the second message isn't. We know that it is not JTA compliant. But some users may still rely on the old behavior to work. Suggestion: a system property can be provided to enable the old behavior if specified by user. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

5
11
0 / 0

[JBoss JIRA] (JBTM-1039) Nm: Very confusing method names (NM_VERY_CONFUSING)

by Amos Feng (JIRA)

Amos Feng created JBTM-1039: ------------------------------- Summary: Nm: Very confusing method names (NM_VERY_CONFUSING) Key: JBTM-1039 URL: https://issues.jboss.org/browse/JBTM-1039 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Amos Feng Assignee: Tom Jenkinson 1.ArjunaCore/arjuna com.arjuna.ats.arjuna.AtomicAction Line 186 VERY confusing to have methods com.arjuna.ats.arjuna.AtomicAction.abort() and com.arjuna.ats.arjuna.coordinator.BasicAction.Abort() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

3
2
0 / 0

[JBoss JIRA] Created: (JBTM-622) Support for crash recovery of tx-inflow with multiple resource managers

by Toshiya Kobayashi (JIRA)

Support for crash recovery of tx-inflow with multiple resource managers ----------------------------------------------------------------------- Key: JBTM-622 URL: https://jira.jboss.org/jira/browse/JBTM-622 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JCA, Recovery, Transaction Core Affects Versions: 4.7.0 Reporter: Toshiya Kobayashi JCA tx-inflow spec allows the external EIS to provide the Xid for the inflowed transaction. The TM handling the inflowed (i.e. subordinate) transaction uses this Xid verbatim when talking to RMs. In current implementation, each RM enlisted in the subordinate tx will see the same Xid as originally provided by the EIS. This screws recovery where multiple resources are involved, since a given Xid no longer belongs to exactly one RM, but may be shared by several. We can no longer return a single XAResource to drive the recovery for a given Xid. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

5
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues February 2012