February 2010 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-486) Refactor log store

by Mark Little (JIRA)

Refactor log store ------------------ Key: JBTM-486 URL: https://jira.jboss.org/jira/browse/JBTM-486 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Transaction Core Affects Versions: 4.6 Reporter: Mark Little Assignee: Mark Little Priority: Minor Fix For: 4.7 The new log store could do with some refactoring. No interface changes or modifications of data structures. -- 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, 1 month

2
5
0 / 0

[JBoss JIRA] Created: (JBTM-673) Investigate other object store implementations

by Mark Little (JIRA)

Investigate other object store implementations ---------------------------------------------- Key: JBTM-673 URL: https://jira.jboss.org/jira/browse/JBTM-673 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Transaction Core Reporter: Mark Little Assignee: Mark Little Fix For: 4.10.0 "... spin out messaging journal into separate component so we can consume it. Also look at other disk I/O alternatives, basically trying to batch syncs so one is shared by many tx rather than one per tx. Also maybe preliminary investigation of in-memory replication of logs via jgroups." See related links. Need to re-check performance of transaction log and maybe make it the default implementation. -- 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, 1 month

2
12
0 / 0

[JBoss JIRA] Created: (JBTM-634) Make sources and javadoc available

by Thomas Diesler (JIRA)

Make sources and javadoc available ---------------------------------- Key: JBTM-634 URL: https://jira.jboss.org/jira/browse/JBTM-634 Project: JBoss Transaction Manager Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Thomas Diesler IDEs like Eclipse and IntelliJ allow you to download sources and javadoc automatically from the maven repo Please make these available for the jbossjta releases -- 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, 1 month

3
11
0 / 0

[JBoss JIRA] Created: (JBTM-633) Generate meaningful POM

by Thomas Diesler (JIRA)

Generate meaningful POM ----------------------- Key: JBTM-633 URL: https://jira.jboss.org/jira/browse/JBTM-633 Project: JBoss Transaction Manager Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Thomas Diesler The POM should contain meaningful information, like dependencies, SVN location, etc Currently this probably generated by deploy:deploy-file <project> <modelVersion>4.0.0</modelVersion> <groupId>jboss.jbossts</groupId> <artifactId>jbossjta</artifactId> <version>4.4.0.GA</version> </project> -- 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, 1 month

3
9
0 / 0

[JBoss JIRA] Created: (JBTM-631) Generate proper maven artefacts

by Thomas Diesler (JIRA)

Generate proper maven artefacts ------------------------------- Key: JBTM-631 URL: https://jira.jboss.org/jira/browse/JBTM-631 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Reporter: Thomas Diesler The artefacts under jbossts (http://repository.jboss.org/maven2/jboss/jbossts/jbossjta) don't seem to be in sync with the project releases. * jbossjta-4.4.0.GA being the latest -- 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, 1 month

3
6
0 / 0

[JBoss JIRA] Created: (JBTM-659) support ipv6

by Jonathan Halliday (JIRA)

support ipv6 ------------ Key: JBTM-659 URL: https://jira.jboss.org/jira/browse/JBTM-659 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Testing Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.10.0 The changes to Uid in JBTM-522 pave the way for full IPv6 support in the codebase. Although ad-hoc testing gives good results, we really need to modify the test setup and servers to ensure a reasonable subset of tests are run on IPv6. -- 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, 2 months

5
22
0 / 0

[JBoss JIRA] Created: (JBTM-576) update unit tests

by Jonathan Halliday (JIRA)

update unit tests ----------------- Key: JBTM-576 URL: https://jira.jboss.org/jira/browse/JBTM-576 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Testing Affects Versions: 4.7.0 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.8.0 There are many unit tests that have lain dormant for some time. Convert them from DTF/junit3 to junit4, wire them to the build and make them pass. This will be done incrementally, one module at a time, following the dependency chain e.g. common, ArjunaCore/arjuna, ArjunaCore/txoj, ... JTA/, .../JTS/... -- 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, 2 months

4
14
0 / 0

[JBoss JIRA] Created: (JBTM-522) Update UID to support ipv6 and ipv4

by Mark Little (JIRA)

Update UID to support ipv6 and ipv4 ----------------------------------- Key: JBTM-522 URL: https://jira.jboss.org/jira/browse/JBTM-522 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Transaction Core Affects Versions: 4.6.0 Reporter: Mark Little Assignee: Mark Little Fix For: 5.0.0 It's possible to have a version that supports both v4 and v6. -- 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, 2 months

5
14
0 / 0

[JBoss JIRA] Created: (JBTM-531) com.arjuna.ats.internal.jdbc.DynamicClass.shutdownDataSource(XADataSource) is never called

by Mauro Molinari (JIRA)

com.arjuna.ats.internal.jdbc.DynamicClass.shutdownDataSource(XADataSource) is never called ------------------------------------------------------------------------------------------ Key: JBTM-531 URL: https://jira.jboss.org/jira/browse/JBTM-531 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Affects Versions: 4.6.0, 4.5.0 Reporter: Mauro Molinari Priority: Critical com.arjuna.ats.internal.jdbc.DynamicClass.shutdownDataSource(XADataSource) is never called by com.arjuna.ats.internal.jdbc.DirectRecoverableConnection. >From what I could understand (but I'm not sure of this), after calling com.arjuna.ats.internal.jdbc.DirectRecoverableConnection.closeCloseCurrentConnection() the DirectRecoverableConnection won't be used anymore, so that method could be a good candidate to call _dynamicConnection.shutDownDataSource(_theDataSource) and to null both _dynamicConnection and _theDataSource. This problem could be quite severe, because if the XADataSource needs to be shut down in order to release resources, this could lead to leaks. Moreover, I was wondering if a caching of the dynamic class wouldn't be a good idea... as of now, a NEW XA data source is created every time a new connection is requested... and this could be expensive... -- 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 months

3
5
0 / 0

[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

12 years, 5 months

4
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues February 2010