February 2013 - jbossts-issues - Jboss List Archives

[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: ------------------------------- Issue Type: Enhancement (was: Feature Request) > 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: 5.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

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1278) Additional debug information required for transaction's Xid with Oracle

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1278?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1278: -------------------------------- Issue Type: Enhancement (was: Feature Request) > Additional debug information required for transaction's Xid with Oracle > ----------------------------------------------------------------------- > > Key: JBTM-1278 > URL: https://issues.jboss.org/browse/JBTM-1278 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Transaction Core > Affects Versions: 4.16.1 > Environment: Jboss EAP 5.x > Reporter: Tom Ross > Assignee: Tom Jenkinson > Fix For: 5.0.0.Final > > > It seems that Oracle is returning different XIDs each time (with the same content) which makes it difficult to debug if the same XID is in more than one scan. Additional debug information is required in Xid to make debugging easier. -- 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

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-860) use XAResourceWrapper metadata for assume complete

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-860?page=com.atlassian.jira.plugin.s... ] Tom Jenkinson updated JBTM-860: ------------------------------- Issue Type: Enhancement (was: Feature Request) > use XAResourceWrapper metadata for assume complete > -------------------------------------------------- > > Key: JBTM-860 > URL: https://issues.jboss.org/browse/JBTM-860 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Resource Manager > Affects Versions: 4.15.0 > Reporter: Jonathan Halliday > Assignee: Tom Jenkinson > Fix For: 5.0.0.Final > > > In the XA protocol a time window exists wherein the RM has committed and thus forgotten a tx branch but the TM has not yet deleted its log. A crash during this window currently results in an unrecoverable situation, as the TM assumes the branch belongs to an RM that is uncontactable and will retry recovery indefinitely. This stems from an inability to relate the Xid to a specific RM. It can be overridden globally with JTAEnvironmentBean.xaAssumeRecoveryComplete, but we would prefer more fine-grained control. With the availability of RM id information from XAResourceWrapper this becomes feasible. -- 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

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1481) Transaction::commit on an transaction that the reaper has tried to rollback but has a wedged resource will not raise an exception

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1481?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1481: -------------------------------- Issue Type: Bug (was: Feature Request) > Transaction::commit on an transaction that the reaper has tried to rollback but has a wedged resource will not raise an exception > --------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-1481 > URL: https://issues.jboss.org/browse/JBTM-1481 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.6.1.CP13 > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 4.6.1.CP14, 4.16.7, 4.17.4, 5.0.0.M2 > > Attachments: JBTM-1481.patch, WedgedResourceDemonstrator.java > > > If you are getting a wedged resource. What then happens is that we interrupt the original reaper thread that is calling XAResource::rollback on the wedged resource which because you are using JacORB and have an in progress call will generate a null pointer exception when the thread is interrupted (you can see this in my attached log file, it prints a stack trace where the logging didn't do so before) which generates a org.omg.CORBA.TRANSACTION_ROLLEDBACK exception. > The problem is that after the reaper tries to rollback the transaction but stalls on a wedged resource, it is then possible for the app thread to unwedged and to do a JTA::commit() and not get an exception. Debugging through the code, it doesn't pose data integrity issues on the transaction as what is happening is that internally we are checking the status of the transaction: > ./ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/coordinator/ArjunaTransactionImple.java:340 > And because the transaction is not RUNNING or ABORT_ONLY, we are: > ./ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/coordinator/ArjunaTransactionImple.java:398: > throw new INVALID_TRANSACTION(0, CompletionStatus.COMPLETED_NO) > Which is all good so far but then ends up in: > ./ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/TransactionImple.java:1425 > catch (INVALID_TRANSACTION e6) > { > /* > * In JTS/OTS we can indicate that something was terminated by another thread. > * JTA doesn't really prevent this, but ... > */ > > //throw new IllegalStateException( > // jtaLogger.loggerI18N.getString("com.arjuna.ats.internal.jta.transaction.jts.invalidtx2")); > } > Where it appears at some point we would have thrown an exception but decided to make the call that this was not valid anymore. > As I say, it doesn't pose data integrity implications to the specific transaction, but if your app thread unwedges and you then make a decision on the outcome of the transaction (send email, acknowledge success) then it would break the business rules of that application. -- 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

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1310) Store JTS participant records with their parent transaction

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1310?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1310: -------------------------------- Issue Type: Enhancement (was: Feature Request) > Store JTS participant records with their parent transaction > ----------------------------------------------------------- > > Key: JBTM-1310 > URL: https://issues.jboss.org/browse/JBTM-1310 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: JTS > Affects Versions: 4.17.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.0.Final > > > In JTA mode participant records are stored together with their owning transaction but this does not happen in JTS mode even when the parent transaction is local. This results in extra log writes thus impacting throughput. -- 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

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-400) Compensation transactions for SOA Platform

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-400?page=com.atlassian.jira.plugin.s... ] Tom Jenkinson updated JBTM-400: ------------------------------- Issue Type: Feature Request (was: Enhancement) > Compensation transactions for SOA Platform > ------------------------------------------ > > Key: JBTM-400 > URL: https://issues.jboss.org/browse/JBTM-400 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Transaction Core, XTS > Reporter: Mark Little > > Needs serious discussions within the team. -- 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

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-400) Compensation transactions for SOA Platform

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-400?page=com.atlassian.jira.plugin.s... ] Tom Jenkinson updated JBTM-400: ------------------------------- Issue Type: Enhancement (was: Task) > Compensation transactions for SOA Platform > ------------------------------------------ > > Key: JBTM-400 > URL: https://issues.jboss.org/browse/JBTM-400 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Transaction Core, XTS > Reporter: Mark Little > > Needs serious discussions within the team. -- 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

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1104) XTS support for load-balanced scenarios

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1104?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1104: -------------------------------- Issue Type: Feature Request (was: Enhancement) > XTS support for load-balanced scenarios > --------------------------------------- > > Key: JBTM-1104 > URL: https://issues.jboss.org/browse/JBTM-1104 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: XTS > Reporter: Paul Robinson > > Enabling session affinity on the load balancer should ensure that all requests for a particular application endpoint, within a particular session, go to the same instance of the web service. > However, XTS advertises a number of endpoint addresses that will not make sense in a load balanced cluster. This is because it would be the internal endpoint address of the particular server that is advertised, rather than the load balancer's external address. > Even if we configured XTS (not yet possible) to offer the address of the LB, we would still have a problem as XTS will use a different session to the application to send protocol messages and thus they will go to a different server that is not aware of this transaction. > h4. Potential Solution > For each web service that is deployed by XTS, we advertises a modified version of the load balancer's address. The modification to the url provides a unique identifier for the particular node in the cluster. The load balancer would then be configured to route messages based on the modification in the url. The LB would also re-write the URL to match that expected by the particular server that receives the message. > This should be configurable per group of services provided by XTS (Client, Coordinator, Participant) as not all of these will, necessarily, be exposed via the LB. > Each Service offered by XTS is deployed via JBossWS. XTS also maintains metadata about the endpoint which it advertises to other participants in the protocol. This metadata is currently kept in sync with the service, but it doesn't have to be. In this situation, the metadata could be configured to advertise the LB address, rather than the actual address of the service. This is also where the URL re-writing would occur to identify the individual node. An example of a class that creates the endpoint metadata is "RegistrationCoordinatorInitialisation". > I don't know what support popular load balancers have for the type of URL re-writing that I mention here. This should be investigated. -- 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

12 years, 10 months

1
0
0 / 0

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

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-223?page=com.atlassian.jira.plugin.s... ] Tom Jenkinson updated JBTM-223: ------------------------------- Issue Type: Feature Request (was: Enhancement) > Check WL-to-JBossTS interoperability (via JTS). > ----------------------------------------------- > > Key: JBTM-223 > URL: https://issues.jboss.org/browse/JBTM-223 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JTS > Reporter: Mark Little > Assignee: Mark Little > Fix For: 5.0.0.Final > > > Extensible header structure corba call > key value slot ids > slot for transaction context is not in the well known slot > tx context was not defined so we used the market leader at the time -- 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

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1472) JTA for Compensations

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1472?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1472: -------------------------------- Issue Type: Feature Request (was: Enhancement) > JTA for Compensations > --------------------- > > Key: JBTM-1472 > URL: https://issues.jboss.org/browse/JBTM-1472 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Transaction Core, XTS > Reporter: Paul Robinson > > We essentially provide a JTA-like implementation for using compensations. We would support distribution over Web services and REST via WS-BA and REST-JDI. This is similar in how we do distributed ACID transactions today; the application is developed against the JTA, but through configuration we enable distributed transactions over a particular transport (remoting, IIOP, WS). > It would be good to have some subset of functionality that worked on a raw VM (i.e. no appserver). This would hopefully broaden the market. -- 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

12 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues February 2013